Apple Looking at ZFS For Mac OS X

Udo Schmitz writes "Apples Filesystem Development Manager, Chris Emura, is looking into porting Sun Microsystems' file system ZFS to OS X. At least this is what Sun's Eric Kustarz states on the ZFS mailing list. Is this a glimpse of hope for all those of us who think HFS+ isn't up to par for a 21st century OS? Next thing you know and they'll rewrite the Finder ..."

Comparison of Filesystems.

Have a look at wikipedia's Comparison of file systems [wikipedia.org] page to see the difference between ZFS & HFS+.

The main advantage for HFS+ users (I mean who's really going to need a 16,000,000 Gigabyte file) would be the introduction of journalling beyond metadata (and even this is unlikely to be useful to most people).

Re:Comparison of Filesystems.

I think the major advantage is the fast snapshotting and cloning. It uses copy-on-write so that it doesn't take more space than what you actually change.

Imagine being able to take really fast working copies of whatever you're doing and be able to simple use the old versions by cd'ing to the old clone.

That's certainly what I would use ZFS for. The rest of the stuff, pooling and mirroring and stuff is less interesting in my laptop. :-)

Re:Think you'll get it?

but the thing that really makes ZFS a completely different beast is that it is (to my knowledge) the first file system (or should I say "storage technology"?) that actually joins two traditionally separate concepts: file systems and volume management.

I can tell you grew up in the UNIX world. Everything I read about ZFS reminds me very much of VMS. Twenty years ago. If you read the UNIX Hater Handbook (published 12 years ago), then you will find a very nice rant about how the UNIX concept of partitions is a huge step back from what VMS offered. Now, over a decade later, it seems someone has listened.

Re:Think you'll get it?

I agree that there was a lot in VMS that the world has "lost". I think that modern UNIX implementations should look at what VMS had, to reuse some of the good ideas that we still have not replicated. My favorite is the security system -- various small capabilities that each user (or program) could be granted. And the super-user only had one capability by default: the ability to grant privileges. I also appreciated the automated versioning, with the ability to pull up a previous version from the filesystem without having to use any special programs.

And yes, I know that Windows NT is sort of descended from VMS. But I've not seen many of the concepts make it up to userland cleanly implemented.

And I'm also aware that VMS is still around. It may not be on life-support yet, but it's clearly in the nursing home already.

Re:Think you'll get it?

Sorry BSD folks, maybe if you whined lounder, we might finally recognize your collective brilliance.

I guess it worked [apple.com].

Re:Comparison of Filesystems.

Since OS X.3, I believe the kernel has defragmented files under 20 MB on the fly [macslash.org].

Re:Comparison of Filesystems.

"HFS+ is subject to fragmentation (but Apple, like MS, provides no tools to help you deal with it)"

Talking in depth to one of the original OS X engineers (there were 4 or 5 depending if you count Jobs as one of them -- they all claimed Jobs gave as much input to the original porting of Next to the new OSX as anyone else did), his claim was that fragmentation isn't a problem.

Apple specifically doesn't offer tools because it defrags files as it makes sense to the operating system -- and generally doesn't defrag at all except for tiny files because modern drive and multiple independent read / write heads on drives today make a bit of entropy a good thing. If I remember later conversations correctly, he also mentioned that Apple had several graphic based disc tools that could do the same things that the OS does on an individual file basis, but didn't see the point in releasing them because this was something that should be left up to the OS and not up to the user. I argued that the user should have control and he countered with the fact that unless you had intimate knowledge about the drives physical features as well as the OSs specific needs, you are more likely going to slow things down in your quest to align the pretty colors together on your defrag program.

What was interesting was that he also recommended that you never fill a drive past 60 or 70 %. The claim was that having a huge chunk of empty space allowed the OS to do its thing without having to resort to smoke and mirrors.

Note -- defragging is an IMPORTANT part to my audience. I deal with musicians and engineers working on digital audio workstations. I remember using specific defraggers that were used solely for our industry (i.e., would write audio files to areas of the disc that were claimed to be the fastest read / write). I followed this skeptically -- until my contact forwarded me to a counterpart of his at Microsoft that essentially said the same thing -- in a MODERN OS using modern hardware, this does more harm than good.

Do I believe that a user couldn't get more optimized use out of defragging their own drives? I don't really know...but I'm going to trust these guys. Do your own research though. For all I know, I was told a line of BS that is intended to keep people like me from poking around under 'modern os`s' :-)

Re:Comparison of Filesystems.

This was actually addressed.

If you keep around 70% of your drive free, the machine will be able to make large enough chunks that given a combinations of other factors it was meaningless.

It was said with multiple independent read write heads, you can actually fill the buffer faster by spreading the load out in noncontiguous sections...and even if it did need to read sequential sections from the same head in different areas, both that the drive can read files nonsequentially and load these chunks into the cache while the other read head is catching up -- and that it takes less than a ms to jump from one sector to another these days.

The clue that was beaten into me was to think of this as sorta a spanned raid within a single drive and that's entirely how these work these days (and then told its entirely not like a raid so I shouldn't use that metaphor lest some nerd that thinks with his head instead of his gut tells me that I'm wrong -- ok I made up the last part, but its essentially what I was told).

But all in all, as other have mentioned, HSF+ likes to defrag on the fly non-contiguous chunks of less than 20 megs (and it will also do this in the background after the CPU is more free after seeing these) -- and given that the average cache on a drive is around 16 Megs, even when this inevitably doubles in the next year or two, the logic remains that this is still good enough.

But you are entirely right -- if drives didn't employ caching and multiple independent read write heads (i.e., early multiple platter systems required that the read/write heads all be driven by the same motor and thus killing any attainable speeds).

Blah blah blah...its all pseudoscience and phrenology to me. I'm just mouthing everything that was sent to me without understanding a word of it. I'm a musician (and technically a pseudoscientist by trade) so making up words and using them incorrectly by mirroring others comes naturally and might even make sense to those that don't know any better :-)

Re:Comparison of Filesystems.

Look up any decent hard disk review site and compare sequential read vs random reads, and you'll see that it suffers quite badly. As for the operating system handling that, I don't know about OS X but Windows certainly doesn't. The "never fill it past 60 or 70%" is simply because than the OS can pick large open chunks, avoiding fragmentation but it does nothing to fix fragmentation. Once your drive has been close to 100%, the last files will be in a zillion fragments all over the disk. They will sit around like little road bumps making sure all other files will be fragmented too.

That said, most desktop users will not notice a big difference between a fragmented, quick-defragment (defrag files, but don't consolidate free space) and full defragmented disk. A typical modern HDD has a 35-40MB/s minimum transfer rate. DV, probably the most resource intensive any normal person bothers with has a measly 25Mb/s = 3,2MB/s. Unless you're suffering from really horrible fragmentation, that should be no problem. Same goes for analog capture with hardware/on-the-fly compression. Yes, there are fringe areas like raw analog video or scientific data but audio capture isn't part of it anymore. And if you're that specific, using a separate tool isn't that big a deal. Servers OTOH might be something, but I imagine most of that is handled by other parts than the OS disk I/O.

HFS+ vs. UFS vs. ZFS

Doesn't OS X already have UFS? ZFS is nicely buzzword compliant, but Mac users can migrate to a standard Unix filesystem today if they want to.

However, I've never bothered to research it and this seems like an appropriate place to discuss it: what's keeping people on HFS+? Is it the case-sensitive thing, and if so, wouldn't that be an issue with switch to ZFS, too?

Re:HFS+ vs. UFS vs. ZFS

ufs does not work with all software especially stupid applications made by microsoft

Re:HFS+ vs. UFS vs. ZFS

From the AirPort page:

This issue is resolved in Mac OS X 10.1 and later.

It's the same deal with the problem with Classic. All 3 items you link to are for OSX 10.0 and have been fixed since then. The number of UFS problems now is minute compared to then.

Great if it's true

But why just ZFS? Why not add JFS or XFS as well? Hell, why not add in ext3 while they're at it? Speaking of which, does anyone have Mac OS X running with a native non-HFS, non-UFS filesystem?

Slashdot is Getting Better Again

A story that consists of a link to wikipedia and a mailing list posting about an OS possibly (maybe, potentially) switching filesystems.

Beats the heck out of story about a blog posting that's just a regurgitation of an MSNBC article that doesn't know what the frack it's talking about.

This is meaningless

Here's a listing of the file systems currently supported on OS X Panther (it may be more for Tiger, I don't know):

$ ls -l /System/Library/Filesystems/
total 0
drwxr-xr-x 8 root wheel 272 14 Mar 12:46 AppleShare
drwxr-xr-x 7 root wheel 238 12 Apr 2005 URLMount
drwxr-xr-x 6 root wheel 204 14 Mar 12:47 cd9660.fs
drwxr-xr-x 3 root wheel 102 22 Dec 2004 cddafs.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:48 ftp.fs
drwxr-xr-x 5 root wheel 170 14 Mar 12:47 hfs.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:47 msdos.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:47 ntfs.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:47 udf.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:46 ufs.fs
$

HFS and UFS are the official choices of file system for installing your bootable OS X or Darwin system. The rest are either network based file systems or are specific choices for interoperability with other operating systems.

There are many reasons why Apple might be looking at ZFS. Only one is that Apple intends to actually make Mac OS X use it as a home filesystem.

Now, here's a reason the write-up author didn't think of: Apple is rumoured to be working on a virtualization layer for OS X, with the intent being that OS X will run in parallel with multiple operating systems. Even if that rumour is false, it's clear that with BootCamp, Apple is taking the idea of Macs running multiple operating systems (albeit not at the same time...) seriously. Solaris and GNU/Linux are the two most popular Intel platforms save for Mac OS X and Windows.

Isn't it more likely that Apple wants Mac OS X its multi-OS Macs to "just work" with the other operating systems, able to achieve a high degree of interoperability without forcing the other platforms to support HFS+?

I'm not saying a move to ZFS would be a bad thing, though it doesn't, so far as I can see, support arbitrary metadata so it'd be as practical as UFS in its current form, which is barely used by Mac users. I just think a port of the main Solaris file systems is, in practice, something Apple would be doing anyway, as part of the Intel OS-agnostic direction they're going in.

Re:This is meaningless

ZFS actually is a ver good file system.

Here is the ars technica low-down on what ZFS does differently and why that's such a good thing.

arstechnica.com/news.ars/post/20051117-5595.html [arstechnica.com]

What Apple Is Looking For

There are probably two things that Apple would be looking for in ZFS: a shiny feature they can point to for their enterprise and video production markets, and for the consumer market, the promise of a simple, reliable way to back up and grow the storage of a Mac without have to worry about mounting/copying/moving volumes, managing backups, etc.

Who stil uses HFS+ anyway?

Dont most of us now use UFS?

And from the view point of a average user, he wont see a difference regardless of what FS hes using..

What ever happened to BeFS?

What ever happened to the Be Filesystem (BeFS)?

I read a few years ago people were doing a GPL'd open version for linux, but since that day have heard nothing...

Is it dead? The BeOS FS was supposed to be absolutely fabulous.

Intel Macs good oppurtunity to make a clean break

I very much wish for an updated filesystem for Mac OSX. I know that HFS plus (with journaling and meta-data searching where added later), I feel HFS + is showing signs of age. I was hoping when Apple first developed Mac OSX it had used the UFS system and then made a separate HFS+ partition for people who wanted to use a Mac OS9 on the PowerPC based Macs, but that didn't happen. Perhaps for the best at the time. Wilfredo Sánchez Vega wrote a whitepaper [wsanchez.net]on the reasoning for HFS + at the time

So now with the Intel Macs and no need for Mac OS 9 support, Apple can tell all their developers that all Universal apps must be able to run on UFS. That way should Apple decide to adopt ZFS it should be a painless transition. Holding on to HFS + with the Intel Macs for this long will hamper any transition into a future filesystem. This will prepare Adobe and Microsoft to write their new Universal versions to be able to accept any type of filesystem and not rely on the resource fork of HFS

That's my 2 cents.

Why stop at ZFS?

I read that Darwin has trouble scaling thread concurrency. Maybe Apple should just switch to Solaris, either licensed or OpenSolaris, and get ZFS with it. (Of course they would still run the MacOS personality and GUI environment on top of it.)

that's nice. now fix network file systems.

I just wish we could come up with a network file system that's worth the trouble. Right now, I'm using a Linux server with three Macs (two Tiger, one Panther), and everything is over NFS. Most of the time, it works fine, but if there's a weird hiccup, then the Mac will freeze solid and has to be hard power-cycled. Also, some apps simply won't run from a network share (or they'll run, but one thing or another won't be right). Install that app to a local drive, and it works fine. And this isn't even to mention security issues.

I've looked at AFP, but that essentially mounts the remote system as if it were an external drive, and assigns everything to the logged in user, so ownership, permissions, etc., are all really screwy. Plus that gets even worse if you use fast user switching -- now two people are independently trying to mount the same network drive, each claiming to own it outright. And it doesn't look as seamless as, say, simply going to /Server/Shared or /Server/Apps.

SMB isn't much better.

There's always AFS, but that's so bloody complicated that I'd take a lot of convincing before I seriously considered it.

This isn't even to mention the problems that most apps have in working in a networked environment -- applications simply aren't designed for, say, networked home directories, and *especially* aren't designed to be running simultaneously on multiple systems. So if I've got Mail.app running in the den and I log in upstairs to check mail just before I go to bed, things could get messed up.

I'm not sure there's even been a new network file system since the mid 90's, has there? Certainly, nothing with broad support that fixes some of these issues? All I want is UNIX filesystem features -- simple locking (I guess), owners, regular permissions. Doesn't even need to do ACLs. Transparently mounted so it looks like it's part of the local filesystem. And at least reasonably tolerant of network glitches, so a momentary drop at the server (or whatever else happens to screw NFS connections to the wall) doesn't put all apps which have even heard of the mount point into an uninterruptible kernel-level deep-freeze (what's the point of kill -9, dammit?). Is that so difficult?

Could make hard drives more reliable

In my November 2005 I posted BlogEd, ZFS and OSX [sun.com], where I described an odd software defect that occured to me on my 17" laptop, and that dissapeared after I reinstalled a new hard drive, after my old one died on me. I am not sure what the defect was due to, but it is clear that with ZFS hard drive corruptions would be detected much earlier. This would be quite a serious advantage.

Reiser4 would be a better choice

For what Apple is doing (desktop, multimedia) Reiser4 would be a much better choice. It offers most of the features ZFS does, is infinitely more feature-extensible and can be optimized for a specific task. ZFS on the other hand is more file-server oriented.

Re:Reiser4 would be a better choice

Reiser4 is transaction-oriented, just like ZFS. The two actually use a similar principle (not journaling) to maintain consistency, based on COW'ing blocks in a tree, then committing the change atomically by swapping the pointer to the root of the tree in the parent node. Reiser4, however, instead of using the traditional block tree ZFS does, uses "dancing trees", which is kind of a B*-tree with ideas from log-structured filesystems mixed in.

Most excellent!

ZFS is one of the more interesting filesystem developments of late. While the address space is nice, it's the data replication features included that make this a potential candidate to threaten the proprietary (and expensive) DR features of modern SAN and NAS storage systems. Need a synchronous or asynchronous mirror? No problem. Just issue a ZFS command on your OSX/Solaris/Linux server...

HFS is big endian

One of the reasons proposed over at Arstechnica has to do with byte ordering. Currently on intel macs, all disk IO has to be byte swapped, degrading performance. ZFS on the other hand will store data in the machines native format.

Even so, all of the other features of ZFS are worth much more than this. If Apple is anything more than a consumer widget company now, ZFS should definitely be under consideration.

ZFS is far from "just another filesystem," and comparing it to existing filesystems indicates a lack of understanding. Take a look at this presentation [opensolaris.org] for more information.

Re:HFS is big endian

Currently on intel macs, all disk IO has to be byte swapped, degrading performance. ZFS on the other hand will store data in the machines native format.

While the non-native byte ordering does slow performance this only applies to metadata and not the contents of the files.

rewriting the Finder

I know this is just a little comment at the end of the story and not the main topic but the Finder really does need to be rewritten. It has a surprising lack of multithreading, even compared to Mac OS 9. This is most apparent (and most annoying) when you are navigating a slow network volume in the Finder. Quite often, you just can't do anything with but wait for the network to time out.

Apple should just buy SUN

The more I think about it, the more it makes sense for Apple to buy SUN. Their products nicely complement each other. Apple is strong in the consumer market and in the creative sector, SUN has good presence in the enterprise, tech and finance sectors. Apple has great brand value and knows marketing like no other computer vendor, SUN has technical excellence, but it's been struggling in the last years to actually sell their stuff. Their products portfolios have little overlap, and together they offer a very complete spectrum of computer products.

Mac OS X is a great consumer OS, but performance at the high end is sub-par. For servers, Solaris is fast and scalable, has nifty features like ZFS and DTrace, but the UI is pretty crude. Imagine a merger of these. Looking at their market [yahoo.com] caps [yahoo.com], Apple can afford it.

Re:Apple should just buy SUN

I like your comment. And the reason why I like it so much has to do with my (past) experience on a University system. Universities developed servers and file sharing with Macs using Sun's servers because Apple really didn't have a server. I mean you could put a Mac (usually an older one) on a network and tell it to share files with everyone but it lacked lots of stuff you would expect to have in a server and it tended to be pretty slow.

I would argue that it was the University exposure that lead Apple to offer Ethernet on Macs. Appletalk was great and people hooked themselves up very quickly with Appletalk (you could buy cabling at your local Radio Shack or use almost any twisted-pair cabling, including electrical cables) but Ethernet was a lot faster and more reliable. I'll bet the folks who developed 10 Base-T Ethernet were thinking Appletalk when they came up with the design for the connector and the twisted pair.

But I digress...

I did a fair amount of work with a hard Science department and they all had Suns as servers. They were strictly Sun Unix for the geeks and they developed systems and applications on that model. But for those who actually had to function in an office environment, the Macs were standard. They used Microsoft's Office for memos, reports and spreadsheets and TeX for document publishing. Everything you did worked.

Frankly, I think this legacy is part of the reason why Apple got fascinated with Unix again (that, and Jobs' NeXt company). It would be a good marriage. Apple's X-Serve RAIDs with Sun. Sweet!

when will it be available for RedHat?

The main goodness of this OS is the ability to chuck hard-disks at it without all that partitioning nonsense. I maintain a repository for a build system and, in the absence of GoogleOS, this would be perfect for storing old releases and the ever-increasing component area.

MacOS X servers are just way too expensive.

unfounded opinions

But Dvorak said Apple was switching to Windows! How could this possibly be true?

ZFS: Finder == Horse: Jockey

Apple is merely picking their horse before they mount their jockey. ZFS is transaction oriented which tells us something about the future. Apple is in the transaction business (iTMS, .MAC, AppleStore, etc...). Expect one hell of a shopping, business centric user experience if they bolt ZFS onto OS X and a killer new user interface to replace Finder.app.

Apple the corporation could "own" the layer above transactions taking a micro percentage in rent/toll for making the experience profitable (ala iTunes).

Database filesystem

Considering that Apple has been working on a database file system (like WinFS, except that it'll actually be released), I'm not sure where ZFS fits in here. Maybe on XServe and XServe RAID, or just as another alternative besides HFS+ and UFS I suppose. But I don't think the dbfs will be based on ZFS.

Partition Resizing

Listening to TWIT I heard a conversation about Parallels and dual booting. Although, obviously not an authoritative source, there seem to be some problems resizing the standard OS X file system for adding Windows to Macintosh computers. Perhaps the resize issue is something they are trying to fix by switching to a more advanced FS? Does anybody know if this makes ZFS more valuable to Apple?

XServe

Perhaps they just want you to be able to take your SUN systems, pull the drives, throw away the box and pop the drives into an XSAN to migrate all of your data over to XServes.

Must I state the obvious...?!!!

All these posts from smart people and nobody's yet mentioned the single biggest reason for Apple to integrate ZFS; to download the internet to that puppy of-coarse! -Leety

Re:YAY!

Hmmm, and why are "resource forks" a huge mistake?

Re:YAY!

HFS+ supports multiple file forks (just like NTFS, except they are called streams under NTFS), but at the moment they are only used for Data and "Resource"

So yeah, Mac's still do have Data and Resource forks, nothing bad about them (OS X is less reliant on them though)

And if you ZIP a file, the Resource fork gets carried along, just with a . added to the beginning of the file name to hide it on UNIX systems, and the hidden attribute set on FAT32 drives (like USB thumbsticks) and such.

Re:BSD leads, Apple follows once again

Obligatory: Why are you waiting on your ass for a feature in an OS for which you have all the code? Drive the development of ZFS on Linux yourself. Ask for help when you get lost, but don't just sit around wasting oxygen.

Re:YAY!

The Mac File Code (eg "WDBN" instead of "DOC") is not stored in the resource fork -- it is in the file index. It's almost identical to MS-DOS extentions except there's no easy way to change them, and they get lost if you copy the file to a non-HFS system.

Re:OT: Context switching...

Task switching between the monitor and the virtualized task is much more expensive than a user-kernel-user switch.

Melissa