Page 1 of 1

trying to resolve a block in OS X

PostPosted: Fri Jul 04, 2014 4:52 am
by gmassenburg
i've recently been re-introduced to OpenZFS and am excited to see the progress. really brilliant work, guys.

i work at a University (Schulich School of Music at McGill University). up to now, our ZFS archives are limited to our Solaris 11 machine. moving forward, we see a great need for a working, supportable cross-platform ZFS filesystem resource.

thus i have been testing 1.27 on a Mac (a Hackintosh for convenience switching between OS's) running 10.9.3, Solaris 11.1, and also on a (new) Mac Pro running 10.9.3. on the new Mac Pro, i have today installed 10.9.4 and the new OpenZFS 1.30 alpha released today.

here're my observations.

1.27 seemed to work well at first running on the Hackintosh, with two 3GB drives formatted with <zpool create -f -o version=28 -O version=5 -O compression=off Zpoolm1 raidz1 /dev/disk5 /dev/disk6>. the filesystem would always mount on Solaris 11.1 and was reliable under testing. on 10.9.3, booting from one other of my two boot drives would result in operations to a known-good zpool failing with a block (<zpool import Zpoolm1> is an uninterruptable blinking cursor). running Spindump from Activity Monitor yields this:

Process: zfs.util [412]
Path: /System/Library/Filesystems/zfs.fs/Contents/Resources/./zfs.util
Architecture: x86_64
Parent: diskarbitrationd [16]
Responsible: diskarbitrationd [16]
UID: 0
Task size: 505 pages
Importance: Adaptive, Donating

Thread 0xf34 DispatchQueue 1 priority 31
1001 start + 1 (libdyld.dylib) [0x7fff9610b5fd]
1001 main + 757 (zfs.util) [0x10e852935]
1001 zpool_import_by_guid + 329 (zfs.util) [0x10e853089]
1001 zpool_search_import + 255 (zfs.util) [0x10e864cef]
1001 zpool_find_import_impl + 1515 (zfs.util) [0x10e863e1b]
1001 pread + 10 (libsystem_kernel.dylib) [0x7fff91d67962]
*1001 hndl_unix_scall64 + 22 (mach_kernel) [0xffffff80002f3f46]
*1001 unix_syscall64 + 499 (mach_kernel) [0xffffff8000640a33]
*1001 pread_nocancel + 137 (mach_kernel) [0xffffff80005f2239]
*1001 ??? (mach_kernel + 4137150) [0xffffff80005f20be]
*1001 ??? (mach_kernel + 2046917) [0xffffff80003f3bc5]
*1001 VNOP_READ + 225 (mach_kernel) [0xffffff80003fe011]
*1001 spec_read + 414 (mach_kernel) [0xffffff800040d47e]
*1001 buf_biowait + 122 (mach_kernel) [0xffffff80003c796a]
*1001 msleep + 114 (mach_kernel) [0xffffff80005e3e42]
*1001 ??? (mach_kernel + 4078613) [0xffffff80005e3c15]
*1001 lck_mtx_sleep + 78 (mach_kernel) [0xffffff800022d18e]
*1001 thread_block_reason + 204 (mach_kernel) [0xffffff8000235d5c]
*1001 ??? (mach_kernel + 223579) [0xffffff800023695b]
*1001 machine_switch_context + 354 (mach_kernel) [0xffffff80002d8262]

the drives are not physically off-line, and are viewable in Disk Utility among other apps and utils.

Screen Shot 2014-07-04 at 9.17.33 AM.png
screen snap of Disk Utility reporting all drives physically on-line
Screen Shot 2014-07-04 at 9.17.33 AM.png (37.67 KiB) Viewed 6797 times

also, when running 1.27 under 10.9.3 OR 1.30 under 10.9.4 on the new Mac Pro ALWAYS blocks. even if i "create" the zpool and am then able to see it, change permissions, and do disk performance tests on it), if i export it and try to re-import it, it blocks at exactly the same point (getting NO P_READ from the pread_nocancel call).

i'd like to troubleshoot this (am an experienced programmer), but am not able to do much without source code.

any suggestions?


Re: trying to resolve a block in OS X

PostPosted: Sun Jul 06, 2014 7:42 pm
by lundman
Hello there,

All sources are of course available in github, and is easy to compile and run. Standard autoconf style layout.

As for your specific problem, I took a look at libzfs_import.c, where we do a readdir() in /dev, and "skip" over known devices to not try to read: ... rt.c#L1134

so I wonder if perhaps you have a /dev/ node we do not, which blocks if you try to read from it. Printing the path, or running import with dtruss, should give
a clue as to what it is trying to do at the time.

Re: trying to resolve a block in OS X

PostPosted: Mon Jul 07, 2014 7:28 am
by gmassenburg
thanks very much lundman!

again, great work on OpenZFS.

so from virgin clones. i've successfully complied spl.kext, but am having trouble with either a Xcode (4.6.3 / LLVM GCC / 10.6 SDK) build, or a command line build.

concentrating on the command line build, the error for ./autogen is: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.

not at all sure what AC_PROG_LIBTOOL should be set to...perhaps <glibtool> (freshly built, now in /usr/share/bin)

so, if i just keep going...

sh-3.2# ./configure CC=llvm-gcc CXX=llvm-g++
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking metadata... META file
configure: error: cannot find install-sh,, or shtool in config "."/config

funny i can't find any comments about this on the net.


Re: trying to resolve a block in OS X

PostPosted: Mon Jul 07, 2014 7:30 am
by ilovezfs
Please follow the instructions here: ... rom_source

Re: trying to resolve a block in OS X

PostPosted: Mon Jul 07, 2014 9:58 am
by gmassenburg
thanks very much.

after i cleared out my old bins and folders everything worked fine.


Re: trying to resolve a block in OS X

PostPosted: Mon Jul 07, 2014 12:39 pm
by gmassenburg

so Lundman's idea of looking at the dev's was the clue. turns out that Avid / Protools has a kext with a device called <com.digidesign.semiface> which is set by <DigiDal.kext>. not sure what it does, and i can run several flavors of Protools 10 & 11 after removing it from /Library/Extensions & /System/Library/Extensions

so i don't see any other /dev's with "com" prefixes, and in the zpool_find_import_impl() method in <libzfs_import.c> i'd perhaps insert
(strncmp(name, "com", 3) == 0) ||

will test this and let you know

thanks for your help, it's great to be up and running with solid source

great work, guys

Re: trying to resolve a block in OS X

PostPosted: Sun Jul 27, 2014 12:42 am
by ilovezfs
The device is named "/dev/com.digidesign.semiface"?

Re: trying to resolve a block in OS X

PostPosted: Wed Jan 28, 2015 5:26 pm
by ilovezfs
The underlying bug is now fixed in master: ... 1223-L1225