Slashdot Mirror
ZFS Set To Eventually Play Larger Role in OSX
BlueMerle writes with the news that Sun's ZFS filesystem is going to see 'rudimentary support' under OSX Leopard. That's a stepping stone to bigger and better things, as the filesystem will eventually play a much larger role in Apple OS versions. AppleInsider reports: "The developer release, those people familiar with the matter say, is a telltale sign that Apple plans further adoption of ZFS under Mac OS X as the operating system matures. It's further believed that ZFS is a candidate to eventually succeed HFS+ as the default operating system for Mac OS X -- an unfulfilled claim already made in regard to Leopard by Sun's chief executive Jonathan Schwartz back in June. Unlike Apple's progression from HFS to HFS+, ZFS is not an incremental improvement to existing technology, but rather a fundamentally new approach to data management. It aims to provide simple administration, transactional semantics, end-to-end data integrity, and immense scalability."
This is awesome and I knew there had to be something more interesting behind Time Machine. While I'm not that impressed with how it appears it's going to work in 10.5, later versions of OS X, with full ZFS support, will make Time Machine damned near magical.
BSD and Solaris have compatible licenses. So new tecchnologies developed in either can potentially migrate to the other. That is, of course, the point of Open Source isn't it?
A filesystem isn't a kernel, so leaping from the incorporation of ZFS into Darwin to a replacement of Mach and/or the BSD bits with Solaris is a bizarre one.
They made a big deal about the import of the latest UFS from FreeBSD in Panther, and their support for UFS was actually reduced in Tiger because they put the Spotlight hooks into HFS+ instead of using the hooks already in the vnode layer in Darwin.
So don't do anything that would depend on them supporting ZFS.
Sun is the new Bell Labs.
Watch for the robotics coming out, very quietly, from Sun in the next 10 years.
Website Hosting
I'll be happy to see them kill that obsolete feature. It's hard to implement everything-is-a-file semantics when some things are files, and others are combinations of random amounts of metadata.
Dewey, what part of this looks like authorities should be involved?
I was amazed to discover though that ZFS can't increase the size of a RAID5 or 6 dataset. Given the ability to dynamically add storage is various other ways it is extraordinary that something as common as resizing RAID5 is missing.
Want to upload that Keynote project to your friendly CMS via a web browser? Can't, because it's not a file, it's a #@$!ing FOLDER. You have to zip it first. Words cannot accurately describe how tiresome this becomes.
It also makes data recovery (should the file get accidentally deleted) nearly impossible- the files inside the folder are not named uniquely or in any identifiable manner.
ZFS isn't nearly all it is cracked up to be- among other things, you can't expand RAID-Z...absolutely moronic. I'm not even sure you can expand a simple mirrored pool. Users have been repeatedly asking for growing abilities, and the developer reaction was "just create a larger pool and move it over". That's hilariously stupid advice given that you usually don't have that kind of storage hanging around- not even in enterprise environments.
There's simply no comprehension amongst the ZFS developers that virtually EVERY raid card on the market supports such an operation. Even more shocking was when one developer said (paraphrasing) "gosh, how would one even go about doing that sort of thing?"
Don't get me wrong- checksumming and automatic disk scrubbing are features long overdue, but ZFS is not magic bullet.
Please help metamoderate.
Case in point, look at the number of nimrods who assume gnu grep and use gnu specific switches for their make scripts.
That's no surprise. The GNU Project competes with Microsoft in the 'Embrace/Extend/Extinguish' derby.
Microsoft says legacy (serial/parallel) ports are bad. They don't obfuscate the hardware enough.
True, but the capabilities of UFS don't really exceed HFS+
In one way, at least, UFS is far better than HFS+.
The internal redundancy in UFS means that so long as the basic file system structures (directories, inodes, and indirect blocks) are intact, it can be repaired. The idea of having file system damage in a bootable file system that can't be repaired by FSCK is all but inconceivable for UFS or any of its precursor file systems. In nearly 30 years working with UNIX, once FSCK was introduced I *never* had a file system so damaged that FSCK couldn't completely restore the structure to working order. Three times now I've had HFS+ file systems require a backup and restore because of some obscure damage that even rebuilding the catalog wouldn't fix. A friend of mine is currently booting his Mac Pro off the second drive because the original installed file system was trashed.
ZFS claims "you'll never have to fsck again". That's what every journalled file system proponent says. That's what they said about XFS... until they came back with tools to do repair and you still had to reinstall to recover sometimes. I'll believe it when I've seen it in practice for a decade or so. What does ZFS do when it hits unrecoverable data in the file system structure itself?
UFS's fsck deals with it by rebuilding the file system structures so that they're valid, and tells you what you lost.
HFS+ tells you that you have some obscure catalog problem and you go out and buy DiskWarrior and hope your backups are in good shape.
XFS apparently gives you a chance to do a final backup.
What does ZFS do? The write-ups on ZFS indicate that they stop short of testing that case, and that's the most important one.