We shouldn't distribute any more binaries with the com.apple.filesystems 
qualifier, since they're 
going to be considered to be Apple rather than us. I propose using 
com.bandlem.mac.zfs as the 
identifer, and will put up support pages there back to this site.

As per zfs_prop.c, zpool autoreplace is not supported yet

The 119 bits were synchronized with OpenSolaris 72, and pool version 8. The 
current OpenSolaris 
release is 125 and the latest pool version is 19

http://www.opensolaris.org/os/community/zfs/version/19/

Using MacZFS-72, if I eject a disk (either with Finder, or by using <code>zpool 
export -f</code> 
then I get a kernel panic. 

This also occurs at reboot (when a kernel panic is involved).

/usr/src/lib/libzfs/common/libzfs_dataset.c
----
/*XXXNOEL this code will work but is hackish 
 */
if (getmntany(mnttab, &entry, &search) == 0) {
    zhp->zfs_mntopts = zfs_strdup(zhp->zfs_hdl,
        entry.mnt_mntopts);
    if (zhp->zfs_mntopts == NULL)
        return (-1);
}
----

Why is it hackish?

Better yet, what is the right way?

There are code paths in the codebase that deal with the read-only extension. 
Since this is no 
longer necessary, deprecate the cases.

fseventd/spotlight monitors changes for items in the filesystem. This makes it 
impossible to 
export a ZFS system without using 

  zfs export -f pool

first

Steps to reproduce the problem:
1. diskutil partitiondisk /dev/disk2 GPTFormat ZFS %noformat% 100%
2. sudo zpool create Test disk2s2
3. reboot
4. sudo zpool status
5. sudo zpool import -f -a
6. sudo zpool status

Expected Results:
The zpool should not have to be imported each time the system restarts.

Actual Results:
The zpool must be imported manually. There have been workarounds posted, 
however the 10a286 bits do not have this issue.

Tested Configurations:
OS:           10.6.1 (10B504)
Arch:        i386, x86_64
mac-zfs: 
http://github.com/dustin/mac-zfs/tree/15cf8709a3e3fd0baef9f2cd920a1cd928a50de2

When you create a pool, it gets created at version 6, even though the code can 
handle up to 
version 8.

Using 'manyfiles' testcase, can generate a panic fairly easily.

<pre>
sudo kextload /target/zfs.kext
/usr/sbin/mkfile 100m /tmp/foobar
/target/zpool create foobar /tmp/foobar
sleep 1
for i in 0 1 2 3 4 5 6 7 8 9 ; do for j in 0 1 2 3 4 5 6 7 8 9 ; do /target/zfs 
create foobar/zfs-$i-
$j; done; done
cd /Volumes/foobar
for i in zfs-*-9; do /target/zfs set compression=on foobar/$i; done
for i in zfs-5-*; do cp -R 
/System/Library/Frameworks/AppleShareClient.framework $i; done
</pre>

This occurs at:

#4  0x343b28d6 in zfs_vnop_reclaim (ap=0x35347c64) at .../mac-
zfs/usr/src/uts/common/fs/zfs/zfs_vnops.c:4419
4419        zfsvfs_t *zfsvfs = zp->z_zfsvfs;

http://github.com/alblue/mac-
zfs/blob/maczfs_72/usr/src/uts/common/fs/zfs/zfs_vnops.c#L4419

Upon closer inspection in a debugger, the zp is null at this point. This 
ultimately comes from:

http://developer.apple.com/mac/library/documentation/Darwin/Reference/KernelIOKi
tFramewo
rk/vnode_h/index.html#//apple_ref/c/func/vnode_fsnode

which gives back the fs-specific data from the vnode. so the problem seems to 
be that we don't 
have any ZFS data with the vnode handed to us at that time (why?) which then 
triggers the panic.

There are two sets of data that are in the OpenSolaris but not MacZFS build in 
kmem.c at maczfs-
72. 

One of these is an audit trail (which may not be useful), and the other is a 
DEADBEEF trail (which 
shows if the memory has been hit or overrun). A simple compile test case 
suggests that the 
DEADBEEF codepath works, and that the #ifdefs surrounding this and other 
codepaths may be 
taken out.

If installing for the first time, the installer generates incorrect permisions. 
It generates ug+rwX,o+rX whereas it should generate u+rwX,go+rX. Unfortunately 
the .pmdoc format is such a train wreck (as is PackageMaker) that it's 
non-trivial to change it. I think the p= is something to do with it, but what 
the right value to poke is unknown.

As per zfs_prop.c, zpool prop delegation is not supported

There's a few #ifdefs around function signatures that are essentially replacing 
vnode_t with struct 
vnode on the OSX port. I wonder why we can't typedef vnode_t to be struct 
vnode? Is this 
something that's defined elsewhere in OSX?

#ifdef __APPLE__
zfs_make_xattrdir(znode_t *zp, vattr_t *vap, struct vnode **xvpp, cred_t *cr)
#else
zfs_make_xattrdir(znode_t *zp, vattr_t *vap, vnode_t **xvpp, cred_t *cr)
#endif

http://github.com/alblue/mac-zfs/blob/master/usr/src/uts/common/fs/zfs/zfs_dir.c
#L876

ZTest may be useful for stress testing the mounted ZFS drives (suggested by  
jason.richard.mcneil)

http://hub.opensolaris.org/bin/view/Community+Group+zfs/ztest

Although the long term goal is to move to new bits, we might also want to play 
around with the 
current build and see if we can tweak out some more performance. I don't know 
how much of the 
performance difference these changes[1] come from just disabling checksums, but 
it if is a long 
time until we can get mac-zfs caught up… well, maybe we can at least make a 
few people happy 
with some better performance.

[1] http://lists.macosforge.org/pipermail/zfs-discuss/2009-September/001855.html

We should release a new binary, or at least, have the mechanisms in place to 
release a new binary 
for the -72 build for those wishing to try out/use on combo systems.

The Share NFS doesn't work. There's commented out commands in the zfs_main as 
well as the 
libzfs_dataset files which prevent sharing from working. These appear to call 
zfs_uninit_libshare; 
whilst Mac doesn't have a 'share' command as such, it does have the ability to 
write into the 
directory and have the NFS shares generated automatically.

$ zpool export foobar
cannot unmount '/Volumes/foobar': Resource busy

This occurs when exporting a pool (without the 'force' flag) as Apple's 
fseventsd is still holding 
onto an open resource (even though it's not using it at present). I suspect 
that the key problem is 
the fseventsd opens a file, and keeps it open, even though the disk isn't 
needed any more.

There may be a way to kick fseventsd in the future so that it goes away, but 
for the time being, this 
message may come up. The workaround is to use zpool export -f foobar.

strings /usr/sbin/zpool | grep maczfs shows no hits.

I only use my ZFS pools for doing an rsync then a snapshot.  During the rsync I 
got a kernel panic.  Strangely it looks like a memory allocation failure, 
yet there was very little running on the system at the time as I was getting 
ready to reboot.  So there was plenty of system memory.  Here is the log if it 
helps:

macpro:~ sam$ cat 
/Library/Logs/DiagnosticReports/Kernel_2010-01-09-110035_macpro.panic 
Sat Jan  9 11:00:35 2010
panic(cpu 2 caller 0x83cca64c): "zfs: vmem_alloc couldn't alloc 131072 
bytes\n"@/Users/dustin/prog/eprojects/mac-
zfs/zfs_kext/zfs/zfs_context.c:700
Backtrace (CPU 2), Frame : Return Address (4 potential args on stack)
0x841f3a38 : 0x21b2bd (0x5cf868 0x841f3a6c 0x223719 0x0) 
0x841f3a88 : 0x83cca64c (0x83d1e838 0x20000 0x20000 0x83cca9ac) 
0x841f3ab8 : 0x83ce527d (0x83d32d94 0x20000 0x0 0x83c82dcb) 
0x841f3b08 : 0x83c81638 (0xe18d800 0x0 0x841f3b38 0x83cca9ac) 
0x841f3b28 : 0x83c8ae3b (0x20000 0x0 0x83d2b270 0x83ce5588) 
0x841f3b88 : 0x83c8b6c4 (0xe18d000 0x0 0x841f3bb8 0x83cca9ac) 
0x841f3bb8 : 0x83c91b44 (0xe89c000 0x20000 0xbf6d1030 0x0) 
0x841f3c08 : 0x83c98c15 (0xbf6d1030 0x13b8b780 0x20000 0x0) 
0x841f3c88 : 0x83c72208 (0xe923270 0x18a37c 0x0 0x841f3ec4) 
0x841f3dc8 : 0x2f98a5 (0x841f3dec 0x3 0x841f3e18 0x57c9b4) 
0x841f3e18 : 0x2ee798 (0x19e9dd7c 0x841f3ec4 0x1 0x841f3f54) 
0x841f3e78 : 0x49606e (0x10e4c9c0 0x841f3ec4 0x0 0x841f3f54) 
0x841f3f18 : 0x4961cc (0x841f3f54 0x10e4c9c0 0x1ad000 0x1) 
0x841f3f78 : 0x4ee947 (0x12b0a540 0xe172b88 0xefa6d54 0x1) 
0x841f3fc8 : 0x29e3fd (0xe172b84 0x0 0x10 0xceb2244) 
      Kernel Extensions in backtrace (with dependencies):
         com.apple.filesystems.zfs(8.0)@0x83c6e000->0x83d32fff

BSD process name corresponding to current thread: rsync

Mac OS version:
10C540

Kernel version:
Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; 
root:xnu-1486.2.11~1/RELEASE_I386
System model name: MacPro1,1 (Mac-F4208DC8)

System uptime in nanoseconds: 1807549187311526
unloaded kexts:
com.apple.filesystems.cd9660    1.4.0 (addr 0x82d49000, size 0x36864) - last 
unloaded 1807447274890616
loaded kexts:
com.parallels.kext.prl_vnic 5.0 9220.531002
com.vmware.kext.vmnet   3.0.0
com.parallels.kext.prl_netbridge    5.0 9220.531002
com.vmware.kext.vmioplug    3.0.0
com.parallels.kext.prl_usb_connect  5.0 9220.531002
com.vmware.kext.vmci    3.0.0
com.parallels.kext.prl_hid_hook 5.0 9220.531002
com.vmware.kext.vmx86   3.0.0
com.parallels.kext.prl_hypervisor   5.0 9220.531002
com.microsoft.driver.MicrosoftMouseUSB  7.0.0
com.microsoft.driver.MicrosoftMouse 7.0.0
com.highpoint-tech.kext.HighPointIOP    2.0.1
com.apple.filesystems.afpfs 9.6 - last loaded 1807345110030968
com.apple.nke.asp_tcp   5.0
com.apple.filesystems.webdav    1.8
com.apple.driver.AppleHWSensor  1.9.2d0
com.apple.filesystems.autofs    2.1.0
com.apple.Dont_Steal_Mac_OS_X   7.0.0
com.apple.iokit.CHUDUtils   201
com.apple.iokit.CHUDProf    212
com.apple.driver.AppleUpstreamUserClient    3.1.0
com.apple.GeForce   6.0.6
com.apple.driver.AudioIPCDriver 1.1.2
com.apple.driver.AppleHDA   1.7.9a4
com.apple.driver.AppleUSBDisplays   2.2
com.apple.driver.AppleIntel8254XEthernet    2.1.1b7
com.apple.driver.AirPortBrcm43xx    421.91.26
com.apple.driver.AppleIntelMeromProfile 19
com.apple.driver.AppleMCEDriver 1.1.9
com.apple.driver.ACPI_SMC_PlatformPlugin    4.0.1d0
com.apple.driver.AppleLPC   1.4.9
com.apple.filesystems.zfs   8.0
com.apple.iokit.SCSITaskUserClient  2.6.0
com.apple.BootCache 31
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib 1.0.0d1
com.apple.driver.AppleFWOHCI    4.4.0
com.apple.driver.AppleUSBHub    3.8.4
com.apple.driver.AppleIntelPIIXATA  2.5.0
com.apple.iokit.IOAHCIBlockStorage  1.6.0
com.apple.driver.AppleAHCIPort  2.0.1
com.apple.driver.AppleEFINVRAM  1.3.0
com.apple.driver.AppleUSBEHCI   3.7.5
com.apple.driver.AppleUSBUHCI   3.7.5
com.apple.driver.AppleACPIButtons   1.3
com.apple.driver.AppleRTC   1.3
com.apple.driver.AppleHPET  1.4
com.apple.driver.AppleSMBIOS    1.4
com.apple.driver.AppleACPIEC    1.3
com.apple.driver.AppleAPIC  1.4
com.apple.driver.AppleIntelCPUPowerManagementClient 96.0.0
com.apple.security.sandbox  0
com.apple.security.quarantine   0
com.apple.nke.applicationfirewall   2.1.11
com.apple.driver.AppleIntelCPUPowerManagement   96.0.0
com.apple.driver.AppleProfileReadCounterAction  17
com.apple.driver.AppleProfileTimestampAction    10
com.apple.driver.AppleProfileThreadInfoAction   14
com.apple.driver.AppleProfileRegisterStateAction    10
com.apple.driver.AppleProfileKEventAction   10
com.apple.driver.AppleProfileCallstackAction    20
com.apple.iokit.IOSurface   73.0
com.apple.iokit.IOBluetoothSerialManager    2.2.4f3
com.apple.iokit.IOSerialFamily  10.0.3
com.apple.iokit.CHUDKernLib 203
com.apple.driver.DspFuncLib 1.7.9a4
com.apple.driver.AppleUSBAudio  2.6.6b2
com.apple.iokit.IOAudioFamily   1.7.2fc1
com.apple.kext.OSvKernDSPLib    1.3
com.apple.nvidia.nv50hal    6.0.6
com.apple.NVDAResman    6.0.6
com.apple.iokit.IONDRVSupport   2.0
com.apple.iokit.IOFireWireIP    2.0.3
com.apple.iokit.IO80211Family   310.6
com.apple.iokit.IONetworkingFamily  1.9
com.apple.iokit.AppleProfileFamily  41
com.apple.driver.AppleHDAController 1.7.9a4
com.apple.iokit.IOGraphicsFamily    2.0
com.apple.iokit.IOHDAFamily 1.7.9a4
com.apple.driver.AppleSMC   3.0.1d2
com.apple.driver.IOPlatformPluginFamily 4.0.1d0
com.apple.driver.CSRUSBBluetoothHCIController   2.2.4f3
com.apple.driver.AppleUSBBluetoothHCIController 2.2.4f3
com.apple.iokit.IOBluetoothFamily   2.2.4f3
com.apple.iokit.IOSCSIBlockCommandsDevice   2.6.0
com.apple.iokit.IOUSBMassStorageClass   2.5.1
com.apple.iokit.IOUSBHIDDriver  3.8.4
com.apple.driver.AppleUSBMergeNub   3.8.5
com.apple.driver.AppleUSBComposite  3.7.5
com.apple.iokit.IOSCSIMultimediaCommandsDevice  2.6.0
com.apple.iokit.IOBDStorageFamily   1.6
com.apple.iokit.IODVDStorageFamily  1.6
com.apple.iokit.IOCDStorageFamily   1.6
com.apple.driver.XsanFilter 402.1
com.apple.iokit.IOATAPIProtocolTransport    2.5.0
com.apple.iokit.IOSCSIParallelFamily    2.0.0
com.apple.iokit.IOSCSIArchitectureModelFamily   2.6.0
com.apple.iokit.IOFireWireFamily    4.1.7
com.apple.iokit.IOUSBUserClient 3.8.5
com.apple.iokit.IOATAFamily 2.5.0
com.apple.iokit.IOAHCIFamily    2.0.2
com.apple.iokit.IOUSBFamily 3.8.5
com.apple.driver.AppleEFIRuntime    1.3.0
com.apple.iokit.IOHIDFamily 1.6.1
com.apple.iokit.IOSMBusFamily   1.1
com.apple.security.TMSafetyNet  6
com.apple.kext.AppleMatch   1.0.0d1
com.apple.driver.DiskImages 281
com.apple.iokit.IOStorageFamily 1.6
com.apple.driver.AppleACPIPlatform  1.3
com.apple.iokit.IOPCIFamily 2.6
com.apple.iokit.IOACPIFamily    1.3.0

add_fsevent: unable to get path for vp 0xffffff800f4e0000 (-UNKNOWN-FILE; ret 
2; type 9)
add_fsevent: unabled to get a path for vp 0xffffff800f4e0000.  dropping the 
event.

No idea what's causing it just yet, but I'm guessing it's something in how my 
fork has filesystems 
show up as separate drives… hoping to find a solution in the 10a286 code.

When plugging in a ZFS pool, the automounter displays 'ZFS is not supported'

Having identified the merge point as (approximately) onnv_72, we should merge 
that in with the 
Github source reference for mac-zfs

There's some commented out code in libzfs_dataset which prevents sharing via 
iSCSI:

http://github.com/alblue/mac-zfs/blob/master/usr/src/lib/libzfs/common/libzfs_da
taset.c#L878

It looks like the GFS is the way that automounted snapshots work on OpenSolaris 
ZFS:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/gfs.
c

For whatever reason, this isn't used (or even present) in the maczfs builds. 
This may be necessary 
in order to use the snapshot dirs.

As well as checking for the existence of the NoFS filesystem, it might be 
prudent to check whether 
there's a key in there or not. The re-write occurs every time the ZFS is 
installed, which is probably 
unnecessary

If you have a Git repository on a Mac OSX ZFS partition, and then attempt to do 
a rebase, you 
get a 'working tree is dirty' error, even when it's clean:

apple:test alex$ git status
# On branch master
nothing to commit (working directory clean)
apple:test alex$ git rebase -i a6c37f4ea9881897650504756a61556015978b96
Working tree is dirty

I have also seen problems with Eclipse and XCode thinking the file has changed 
on the file 
system (when it hasn't). 

It transpires that you can do this:

apple:test alex$ git config --global core.trustctime false
apple:test alex$ git rebase -i a6c37f4ea9881897650504756a61556015978b96
Successfully rebased and updated refs/heads/master.

So there's obviously some kind of bug/inconsistency with the 'ctime' of the 
file which is causing 
this behaviour. It may be related to the stat/stat64 issue inconsistency.

If installing a ZFS pool on a USB disk, and then yanking before it is 
unmounted, then the OS 
suffers from a kernel panic.

Emptying the trash with a ZFS-mounted home directory fails to work. Apparently, 
this is an 
"iterator problem" according to Noël:

  Also, the Trash not emptying bug was due to an iterator issue (ZFS counts '.' and '..' as items) 
and not a Finder issue.

10.5 added stat64, and the OpenSolaris codebase uses stat64 a lot. However, in 
10.6, stat is 
preferred.

There's an #ifdef that can support using either (according to the man page): 
_DARWIN_USE_64_BIT_INODE

There's code around some stat/stat64 methods as follows:

#if _DARWIN_FEATURE_64_BIT_INODE
                struct stat statbuf;
#else
        struct stat64 statbuf;
#endif

However, this seems to be different to the _DARWIN_USE from the man pages vs 
_DARWIN_FEATURE from the (current) code. Yet more uses __APPLE__ around such 
differentiators.

There's a few places where we have IFDEF'd code like:

#ifdef __APPLE__
                        vnode_put(ZTOV(attrzp));
#else
                        VN_RELE(ZTOV(attrzp));
#endif

If we can conditionally change the VN_RELE action to do a vnode_put instead, 
then we may be able 
to avoid such ifdefs littered around the code.

Using zfs send | zfs recv doesn't work.

There is a workaround, which is to do:

mkfifo foo
zfs send > foo &
zfs recv < foo &

although this is clearly less than desirable

The libzfs has a hashdef for TEXT_DOMAIN=0, which looks like an odd build 
setting to put in place. I suspect that we can handle this in a global includes 
file instead.

We can use xcodebuilder install to generate an install-like builder, but this 
only works for the 
current architecture. Ideally we need to use something like pmdoc to generate 
an installer which 
can work for both architectures and use a mpkg to deliver them concurrently 
whilst installing only 
one. Using something like:

xcodebuild -sdk macosx10.5 DSTROOT=macosx105 install
xcodebuild -sdk macosx10.6 DSTROOT=macosx106 install

will generate two file system paths, which we can then bundle into either a 
flat package or a meta 
package containing two bundles.

What steps will reproduce the problem?
1. I have a raidz2 8 drive pool made up of 4 x 1TB drives and 4 x 1.5TB drives
2. I put a new 2TB drive into an available slot on a hot swappable FW800 
enclosure I have and 
issued a zpool replace command

What is the expected output? 
I expected the replace to happen in a timely manner. 

What do you see instead?
I had the black multi-language screen from a panic. The replace appears to be 
running but it has 
been 3 days now.

What version of the product are you using? 
zfs-10a286
iMac: joel$ zfs upgrade
This system is currently running ZFS filesystem version 3.

All filesystems are formatted with the current version.
iMac: joel$ zpool upgrade
This system is currently running ZFS pool version 11.

All pools are formatted using this version.
On what operating system?
10.6.2
Darwin iMac.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 
2009; root:xnu-
1486.2.11~1/RELEASE_I386 i386


Please provide any additional information below.
As it turns out I'm not a very good UNIX administrator and had the pool at 96% 
capacity when I 
tried the replace action.

Nofs.fs is only installed on Snow Leopard; it's not present on Leopard. The 
installation fix script 
will fail if the path doesn't exist.

alblue:install_support alex$ ./a.out 
2009-10-25 09:39:04.366 a.out[7973:10b] Error reading plist: stream had too few 
bytes, format: 
0

This in turn causes the installer to fail, since the error code is propagated 
upwards.

Creating an installer package is error-prone - we should adjust the make files 
to do this so that 
others can also build packages

The icon is defined in:

/System/Library/Filesystems/zfs.fs/Contents/Resources/VolumeIcon.icns

If we have a different/improved version, we can change the default icon that 
gets mounted on the 
desktop. We should have a vector art, including up to 512x512 (providing that's 
backward 
compatible with Leopard) in an .icsn format.

The gzip compression isn't supported. If you look at the zfs_main command, the 
option for 
enabling gzip compression is missing.

Further, the body of the gzip_compress function has been arbitrarily commented 
out (it's hard-
coded to return -1). 

http://github.com/alblue/mac-zfs/blob/master/usr/src/uts/common/fs/zfs/gzip.c

size_t
gzip_compress(void *s_start, void *d_start, size_t s_len, size_t d_len, int n)
{
#ifdef __APPLE__
    return(-1);
#else
...

Would be good to find out why this is the case, and see if we can fix it at all 
so that we can 
enable GZip compression for those that want/need it.

The manpages are available from:

http://dlc.sun.com/osol/man/downloads/current/

The latest (at the time of filing) is 

http://dlc.sun.com/osol/man/downloads/current/man-sunosman-20090930.tar.bz2

Note: I think this is all man pages, not just ZFS ones.

usr/src/common/zfs/zfs_deleg.c
---- 
/*Need a isdigit defined for kernel space*/
#ifndef __APPLE__
            if (!isdigit(*p))
                return (-1);
#endif
----

I think there is code to 10a286 that address this… I'll look into it soon.

There's a bunch of refs to atomci_add_64 in the arc.c that are commented out 
with an #ifndef 
__APPLE__. There doesn't appear to be a reason why we shouldn't use the 
built-in atomic add in 
this case. 

ZTest depends on libumem, which isn't currently included.

In Leopard, a ZFS pool is shown as a removable volume, and files are shown as 
symlinks.

This is a Finder bug in 10.5, which is apparently fixed in 10.6.

If launching a scrub/snapshot/destroy simultaneously, it's relatively easy to 
create a kernel panic. 

We don't need the fix-nofs any more, since

http://github.com/alblue/mac-zfs/commit/70194d2c84b9fea26551411c671792768b7bca58

will take care of the nofs issue without needing to change Apple-supplied code 
(and therefore potentially not break any of their signatures)

The ZFS 119 bits are only compiled for 32-bit operating systems at this time. 
They don't work 
under a 64-bit snow leopard, but are rumoured to do so for a 32-bit snow 
leopard.

zoink and ztest are utilities only needed by developers; neither they (nor 
their manpages) need to 
be installed on end user systems. Can we have an optional install, defaulting 
to 'no' (unchecked) 
to install these utilities?

ZFS supports automounting of snapshots via the .zfs directory. This wasn't 
available in the 119 
bits.