Not so easy I could do it, though
ZFS is the übercool Solaris file system cum volume manager cum software RAID now being ported to Apple’s Leopard (see ZFS On Mac: Now All But Official and ZFS: Threat or Menace?. Lots of skepticism from people who can’t imagine another file system – even with all the functionality of ZFS – in place of um-m-m, ah – whatever file system Mac OS X is using today. Journaled HFS+?
Oooh-h-h it’s so hard . . .
Much of the objection to a wholesale movement from HFS+ to ZFS is that it is so hard to do. But is it really? Of course the engineers involved are telling their bosses and their buddies how hard it is, even if they’re playing Halo six hours a day. Honestly though?
Maybe not super-easy, but read on
In Technical Q&A QA1242, updated a couple of months ago, Apple talks about their new VFS plug-in architecture in 10.4.
Prior to the introduction of Mac OS X 10.4 Tiger, the BSD portions of the Mac OS X kernel were not architected for binary compatibility. . . . The slightest change to the kernel (reordering the fields within a structure, for example) would break all VFS plug-ins.
With Mac OS X 10.4 Tiger, Apple has solved this problem by introducing a VFS Kernel Programming Interface (KPI). . . . you no longer access fields in kernel structures directly; rather you call accessor functions that are supplied by the KPI. By using this KPI you can develop a VFS plug-in with the expectation that it will be compatible with future systems.
Leaf it be
The KPI is designed for Leaf File Systems, which include
- Local file systems
- Network file systems
- Cluster file systems
I know you’re thinking: what other kind are there?
A stacking file system (sometimes called a filter file system) sits on top of another file system and modifies its behavior in some way. The canonical example . . . is an encryption file system. You could stack this file system on top of any existing file system to provide encryption support.
A telling admission
Apple then goes to say that they don’t support stacked file systems because they don’t see how to make them reliable, fast and compatible with future OS versions. Pretty good reasons, IMHO. But they used to think they could:
Note: Earlier Apple documentation stated that stacking VFS plug-ins could be used to solve certain problems, such as file-level encryption and virus checking. We even went so far as to publish an example of this, the Politically Correct file system (PCFS), that ran on pre-release builds of Mac OS X. Subsequent experience has shown that this technique does not work properly and we no longer support it.
Engineers hate it when they have to back track like that. Someone must have believed it possible to get as far as they did. The important thing is that it demonstrates the ambition of the Apple engineering team for really cool file system capabilities.
Speculation is the father of invention
It looks like they figured out that stacking file systems probably wouldn’t work about 18 months ago (they inserted the bug tracking number for stacking file systems a year ago). They’d already started working with Sun on DTrace by that point, and since Sun’s DTrace and ZFS teams know each other, there was probably some engineering over Indian food and beer. Thus ZFS on Mac took flight.
Making VFS robust
In December Apple added sample code projects for EmptyFS and MFSLives that give developers something to help develop and test their ideas. These tools are likely a by-product of making the VFS interface robust enough to support ZFS and – who knows – maybe some other file systems.
The StorageMojo take
Apple sees real demand for file system alternatives on Mac OS X, in addition to their own plans for ZFS. This is good news for the consumerization of IT: enabling new file systems to be tested and deployed on high-volume workstations and servers should encourage innovation. Kudos to Apple for opening up the VFS KPI.
Comments welcome, as always. Especially if you know more about VFS than I do. Not a very high bar. Moderation turned on because I love getting mail.