ZFS
Back in June, MacJournals wrote a 13,000-word article that explained some of the virtues of ZFS and gleefully debunked the (crazy) rumor that it was to be the default file system in Leopard. Amid solid points about areas where ZFS falls short compared to HFS+ was much sneering at “command-line-addled ‘everything invented by Apple must be evil’ true believers” who want Apple to switch to ZFS. (It was the Attitudinal, after all.) A few days ago, AppleInsider wrote a fairly typical rumors article about ZFS and Leopard. MacJournals responded with snark, which was not appreciated by Drew Thaler, a former Apple filesystems engineer. And now MacJournals has responded to Thaler, saying “You don’t have to hate ZFS to know it’s wrong for you.”
My opinion is pretty well summed up by Thaler’s statement in the comments:
If you’re an OS engineer and you aren’t hard at work solving the problems intrinsic to that TODAY, you’re not doing your job. HFS+ is “not that bad” for today’s needs. It’s going to be woefully inadequate real soon now.
ZFS isn’t ready to be the default Mac OS X filesystem today, but HFS+ is or soon will be a liability, and ZFS is perhaps the best candidate for its eventual replacement. Some features like snapshots and merging multiple drives into a storage pool may not make sense for all consumers, especially on notebooks, but there’s no requirement that they be used. There are still data integrity features that could benefit everyone, as I was reminded this weekend when I had problems with the catalogs of two HFS+ drives. And, personally, I think snapshots and pools will be relevant to consumers sooner than people think.
The problem is that, as MacJournals explains, ZFS (as it currently stands) can’t be a drop-in replacement for HFS+. It supports filenames only half as long. It’s case-sensitive rather than case-insensitive/case-preserving. It has inefficient storage for certain extended attributes. Thaler thinks the filesystem should be case-sensitive and the insensitivity should be layered on top by the application frameworks. This wouldn’t be perfect, but I think it could be “good enough.” (The current situation isn’t perfect, either; relying on the filesystem’s case folding means that some software won’t work properly on UFS or HFSX.) Apple to date hasn’t shown much interest in using extended attributes, so I think MacJournals’ concerns about increased space consumption under ZFS are overblown. Of course, I hope that Apple will start using extended attributes more, and if they do that could become a problem with ZFS.
So what’s the way forward? Apple could stick with the current HFS+ or try to add more features to it. It could use ZFS or its own customized version of ZFS. Or it could use another filesystem entirely. I have no inside information, but my guess is that Apple will eventually ship Macs that boot from some version of ZFS. Perhaps it will make changes to ZFS and try to get them into the official version. I don’t think this is an area where it makes sense to swim against the tide. Users may end up having to make a few concessions, but frankly I think using 128-character filenames instead of 256-character ones is a great tradeoff in return for ZFS’s data integrity features alone. (Use of super-long filenames is limited due to OS X’s PATH_MAX, anyway.)
Update: Jesper covers a point I made above, but should have emphasized more: “‘Everything on’ isn’t the only way to run ZFS.”
Update 2: MacJournals responds to my post, still emphasizing the large storage pools and mirroring, but its main target seems to be “ZFS fans dishonestly asserting all of its ‘magic’ properties without honestly discussing its limitations.” I hadn’t seen much of that, but I try to avoid fanboy circles.
Update 3: Drew Thaler responds. I don’t understand why more people aren’t bothered by the error rates with today’s hard disks. This is one of the reasons that EagleFiler checksums all the files in its library.
Update 4: MacJournals responds to Thaler’s response. In the original article, they said ZFS was “completely unsuitable for a Mac OS X startup disk, now or in the foreseeable future.” Now they say, “We do, however, reject the notion that everyone would be willing to make that compromise with today’s hardware. We believe those who are should have the option,” which is basically what I think. It should be an option, soon, for those whose data and drive(s) are such that ZFS wouldn’t use too much disk space or be too slow. There’s also a strange part where MacJournals seems to suggest that Apple should try to integrate ZFS ideas into HFS+ or else build an entirely new filesystem. “The entire discussion of filesystems is skewed, from the start, towards the default position that Macintosh-related filesystem constructs are somehow bad.” I think it’s, rather, that some of us wanted certain ZFS features yesterday. ZFS already exists, and it could provide real benefits relatively soon. The other approaches would probably take much longer, for relatively little benefit. The primary reason for Apple to re-invent the wheel (unless it already has a secret project to do so that’s near completion) would be if it had the attitude towards Unix and open source that MacJournals ascribes to ZFS fans and Mac technologies (which, for the record, I tend to like).
