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."

Buzz compliant

[suv4x4]

end-to-end data integrity

You can't talk about end-to-end data integrity when this is just a filesystem. It's only one tiny place where the data you store in said file system can wreck its integrity. Are there memory bus or in-memory check for integrity of data read from ZFS? What about applications?

Also stop talking to ZFS. Very secret internal sources told me ZFS was supposed to be a bigger event in Leopard but Steve killed it because Sun scooped him. It has happened before folks!

Don't scoop the Steve. You scoop the Steve and business is over.

Non-Standard my ass!

[kaiwai]

I'm hoping not, since many things behave very oddly on Solaris. Non standard tools and such, but it would be one way to keep it from running on cracked PC's.

What are you smokeing - what ever it is, pass it this way. Non-standard or 'does not conform to the bastardised standards which GNU have embraced and extended'. Case in point, look at the number of nimrods who assume gnu grep and use gnu specific switches for their make scripts.

It isn't Solaris that it is non-standard, it is those who insist on using GNU tools and their extensions to the standard which are the non-standard.

Re:Buzz compliant

[caseih]

That's Steve's loss then. Too bad his own ego often gets in the way of things that could benefit the customer. Honestly, why should Sun really care what Jobs does with ZFS in the long run. Sure it'd be good for Sun in terms of publicity, and maybe even some royalties. But in the long run, I can't see it being that big of a deal for Sun.

built in LVM == Win

[mikeee]

Actually, a built-in LVM makes a lot of sense if you stop to think about it; many of the things a LVM does could benefit from information only the filesystem has.

Re:They said the same thing about UFS.

[flaming-opus]

True, but the capabilities of UFS don't really exceed HFS+. ZFS, on the other hand, is a thoroughly modern filesystem. UFS is just as rusty as HFS+.

oh, puhleeeze

[m2943]

Even though OSX will still be Unix, will they'll move away from BSD and toward Solaris?

OS X is a heavily hacked Mach kernel with a bit of BSD code thrown in. Its architecture and codebase are completely different from UNIX. So, apart from a bit of UNIX compatibility and a lot of marketing hype, OS X is not UNIX.

Will they "move towards Solaris"? I have no idea what that even would mean.

Re:Does anyone proofread these articles?

[phliar]

It probably won't happen anyway. ZFS wasn't invented at Apple, and thus will never become an important part of 'The Mac.'

And Unix wasn't invented there either, but I'd call OS X "an important part of 'The Mac'".

Re:Does anyone proofread these articles?

[Durandal64]

Apache wasnt invented at Apple. Neither was Samba. Neither was SSH. Neither was gcc. All of these things are very important in Mac OS X.

Re:UFS has an FSCK that really works

[Anonymous Coward]

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.

This has nothing to do with 'internal redundancy', it has to do with filesystem metadata not being as easy to damage. UFS maintains a kind of free list to allocate new blocks, whereas HFS+ and JFS and XFS use bitmap allocation. If you stomp on part of a bitmap it's way worse than stomping on part of a list. ZFS on the other hand has a tree of blocks and can keep a configurable number of redundant copies on each drive and there are sometimes older copies that exist depending on how full the filesystem and how much has been written.

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.

That's nice. In 20 years working with Unix and Unix-like systems I have had several UFS filesystems be unrecoverable with fsck. I've had a JFS be *completely* destroyed just by doing sync() calls too often. Probably you were using the good hardware that UNIX (as opposed to Unix or Linux) typically runs on.

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.

Can I suggest not filling your drive up completely with porn and movies and music or whatever else you are filling up the drive with? HFS+ has a problem when more blocks need to be allocated for the catalog and there are no blocks which can be used, it ends up with files and catalog sharing blocks and the catalog getting destroyed catastrophically. It could be fixed but it looks sufficiently annoying that they would rather have it occasionally fail instead of messing with it.

Conceptually HFS+ is far better than UFS, the problem is just one of implementation.

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.

It is written up in many places, you just missed it. ZFS keeps a configurable number of backup copies of any metadata and all metadata is checksummed separately, so even on a single drive it's almost impossible for the data to not be recoverable. Because the filesystem itself can detect all errors (other than the 1 in 2^160 chance of an error *and* hash that perfectly matches it) it does the repairs itself (other fs don't know if a block is wrong so they can't fix it easily, which is why you need a separate tool). There could be a use for a separate tool that would recover partial files, ones that had been deleted a long time ago and part of its blocks reclaimed, but there's no need for a fsck and this is not possible with other filesystem anyway (since they rewrite in place
).

ZFS claims "you'll never have to fsck again". That's what every journalled file system proponent says.

ZFS is not a journaled filesystem, it's a log-based one. "Journaled" filesystems only journal the metadata, because they have to do everything twice: first write to the journal anything that should be guarenteed, then wait for it to sync, then write the data to the 'disk'. A log-based filesystem basically writes the 'diff' to the disk then says 'this is the new state'. It's more like a (good) kind of subversion or version control that forgets old revisions from time to time.