Well it looks like the Apple implementation of ZFS will not be included in the upcoming Snow Leopard release. I admit to being somewhat disappointed that it didn’t make the cut, but as I’ve been following the beta development, it’s really not ready for prime-time wide scale implementation. They’re still working hard on it internally, and I fully expect to see it out in the real world, but not before 10.7.
There are a number of rather complicated issues that they have to work through and I’m glad to see them pull it, rather than put out some kind of half-assed implementation. Notable issues that are still in the works are dealing with ZFS’s not so great handling of USB volumes. Given that the vast majority of external disks used by Mac users are USB, this is a deal breaker. I’ve managed to kill a few mirrored zpools in my tests with unexpected disconnects and the like. Once they get a clear handle on this (which will require some more maturity of this code in the core ZFS implementation) I’ll be more comfortable with this option.
The second issue that I’ve noted is that there’s still no good consensus on how to map zpools and zfs filesystems into the current HFS oriented volume management user space. Creating a zpool creates a volume and is presented on the desktop as such, which is not exactly the intent of ZFS. The pool is the root, but not necessarily meant to be visible in the user space - it’s the individual filesystems in the pool that need to be mounted. But this begs the question - where to put the pools in the meantime?
There are also some HFS and fsevent semantics that don’t map over cleanly, which can result in applications not working properly (Spotlight being the number one culprit). Also some details surrounding how some of the default features would be implemented like NFS and iSCSI sharing since the necessary OS infrastructure is missing (at least for iSCSI) and the fact that these settings are part of the filesystem definitions so by moving a pool to another machine it should automatically be able to publish the filesystems according to the built-in settings. NFS should be doable, but there’s still the attachment problem, on Solaris (and variants, a pool defaults to a directory at the root of the filesystem environment, while the OS X implementation maps it to /Volumes which would break NFS paths since it’s not in the same place when you move a pool between environments. The lack of an iSCSI target daemon means that the shareiscsi=on settings will be ignored until Apple ports over the target code which given the reliability requirements is a non trivial task.
So I’m disappointed that it didn’t make the cut but I’m also glad that they’re waiting on getting it right before release.
In the meantime, my ZFS server (OpenSolaris) is quite happily serving up NFS and iSCSI volumes for Time Machine, online media, archives and overflow from my MacBook Pro’s internal drive. I highly recommend it as the best possible solution for data consolidation. I even have some volumes served up to OS X Server via iSCSI, which then publishes them as Time Machine volumes for some portables on which I didn’t want to install the iSCSI client. Once I get some more space (and an off-site backup solution in place) I’ll be migrating all of the user home directories over to a volume mounted from the ZFS server and the OS X Server environment will be only the boot environment and essential core services.
PS - I’m using the GlobalSAN iSCSI Initiator