Originally Posted by Kickaha
Indeed - you have to not only ensure that it works with the new API (which may be fairly trivial), but also that older apps that use legacy, more direct-to-metal HFS accessors still work as well. That can be... a pain.
Of course, the sooner you deprecate those old APIs (*cough*Carbon*cough*) and drop support for them, the faster you can do this cleanly... but given the realities of the market, 'fast' is still going to be measured in years.
OK, now things have gotten to the point where I have to say something.
First, there are many reasons why ZFS is not ready for consumers. First, ZFS is relatively slow. In an enterprise environment the speed is a calculated tradeoff for other features not needed by the average customer like storage pools and redundancy, but even Sun's own ZFS implementation is still slower than some older filesystems like HFS+, and an order of magnitude slower than newer filesystems like NTFS. Sun has publicly stated on its dev forums that it is working on the speed, but consider what ZFS has to do and it's not a trivial task. They are now moving in the driver direction--offload some work done by ZFS onto the disk driver when it has the capabilities, but many low-end hard drives (read: cheap) don't have the hardware features, or sufficient hardware, to do it. Perhaps Apple will find hard drives for their server solutions that support the in-hardware checksumming for ZFS.
Second, there are no APIs in userspace that allow users to write to the "metal". Any program that does (mainly disk editor programs like DiskWarrior) is not using any API that Apple wrote, they are writing to the raw block device directly. Of course those programs will have to change, and it's a big reason Apple is most likely not including ZFS in a consumer OS--there'd be no way to recover a drive once it fails (and hardware does fail).
Third, snapshots are not going to be used by TimeMachine anytime soon. Snapshots sound nifty and their ZFS implementation is very good, but in reality they are a big drain on the filesystem when used for backup. Sun publicly states in its ZFS userguide that snapshots are NOT a backup solution, for a variety of reasons (some stated here before). One big problem is that snapshots for directories are all-or-nothing. That is, the entire directory snapshot must be restored to restore a single file. So single file snapshots would have to be used for a backup solution, but single-file snapshots are much more disk intensive--creating a data structure and snapshotting every file on the drive will be pretty IO intensive.
Lastly, the so called "Carbon" Filesystem APIs referred to above are actually used heavily in Mac OS X, and are not Carbon APIs but rather CoreServices APIs. Cocoa in fact uses them extensively, as you can see by simply disassembling the Cocoa framework. FSRefs were invented in the OS 9 days to be filesystem independant opaque objects for a filesystem inode, and they perform quite admirably. There are many APIs available for FSRefs not available at the BSD layer, such as FSCopyObject (there is no such thing as copying a file at the vnode layer), FSMoveObject (again, only renames exist in the vnode world), etc. These are all wrappers used heavily by the Finder and Cocoa. So there's no f'ing way Apple is deprecating them, and in fact as of last WWDC was encouraging developers to use them pretty heavily. Leopard introduces no new filesystem API, only additions to the FSRef APIs and a new Alias Manager replacement that uses more modern data structures (but still uses FSRefs underneath when it has to).
Having said all this, I wish ZFS were an option for the client version of Mac OS X, and it wouldn't surprise me if they do make it available in an inline after 10.6 ships.