ZFS Confirmed In Mac OS X Server Snow Leopard

number655321 writes "Apple has confirmed the inclusion of ZFS in the forthcoming OS X Server Snow Leopard. From Apple's site: 'For business-critical server deployments, Snow Leopard Server adds read and write support for the high-performance, 128-bit ZFS file system, which includes advanced features such as storage pooling, data redundancy, automatic error correction, dynamic volume expansion, and snapshots.' CTO of Storage Technologies at Sun Microsystems, Jeff Bonwick, is hosting a discussion on his blog. What does this mean for the 'client' version of OS X Snow Leopard?"

Comments

What does this mean for 'client'?

[daveschroeder]

Nothing, in particular. It means that ZFS isn't going to be officially supported and/or promoted on client. But, since Mac OS X and Mac OS X Server are essentially the same OS with some different/additional pieces on the top of Server, and like other filesystems that were exposed via the GUI tools and supported on Mac OS X Server, but not on Mac OS X, in the past -- such as Mac OS Extended (Journaled, Case-Sensitve) -- it will likely be available via the command line tools, and usable by people savvy enough to work with other boot devices to format the volume in the desired fashion, etc.

Re:What does this mean for 'client'?

[larry bagina]

10.5 client includes readonly zfs support. The mac ZFS development is available here

Re:What does this mean for 'client'?

[Goaway]

You should perhaps consider taking the internet less literally.

Re:What does this mean for 'client'?

[Anonymous Coward]

The fact that no one has refuted it can be seen as proof enough that the claim is so preposterous as to render such preposterousness self-evident and therefore unworthy of refutation. Additionally, your ability to receive intellectual "hand-outs" is stymied by said lack of refutation. Ergo, your desire for more information will go unfulfilled. However, being the bleeding-heart that I am: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Memory_and_Swap_Space and, for future reference, http://www.google.com/

Re:What does this mean for 'client'?

[spun]

From what I understand, ZFS is fast not memory efficient. Minimum recommended system memory is 1GB, more is definitely better.

I'm no expert on ZFS, I just did a google search on 'zfs benchmark' and then on 'zfs memory usage' and pulled information from the first few results. Maybe someone who actually knows something can chime in?

Re:What does this mean for 'client'?

[the_B0fh]

The moon is made of green cheese. Until someone refutes that, you can continue to think so.

Seriously though, zfs for osx is already available to be checked out and played with. Additionally, they hired one of the key zfs people and have her working on zfs for osx now.

I highly doubt it will suck, since, iirc, she was one of the people who worked on the test sets that SUNW^H^H^H^HJAVA runs nightly.

Re:What does this mean for 'client'?

[Just Some Guy]

From what I understand, ZFS is fast not memory efficient.

Nitpick: it definitely likes a lot of RAM, but it doesn't necessarily use it inefficiently. Car analogy: a semi truck is fuel efficient, even though it's gas mileage is a lot lower than a sedan's.

"All features on this page are subject to change"

[TibbonZero]

It should be noted at the bottom of the page.
I was under the impression that they had initially hoped to include such in Leopard.

However, it isn't just Apple, Microsoft has been working on various structured file systems (WinFS through OFS and Storage+) for nearly 20 years with no shipped products

How will I benefit?

[The Ancients]

Ok, I'm reasonably technical, but not savvy with the intimate workings of a file system. What will this mean for the average user with an iMac or MacbookPro, when ZFS finally appears as the default FS of OS X? Will it be faster, more error-resistant, or...?

Re:How will I benefit?

[Cyberax]

It probably won't be faster (and may even be slower), but it definitely will be more reliable.

ZFS uses super-paranoidal checksumming which can detect drive problems in advance.

Re:How will I benefit?

[countSudoku()]

You'll also be able to create a pool of drives that acts as a single drive, like you can with the RAID setup now, but far faster to setup. Growing your pools is a breeze and if they can tie TimeMachine into the zfs snapshots, my god, what can't we do?! Seriously, this will be a nice advanced file system for Mac OSX. We've been using it on Solaris for a year now for zone root/usr file systems, and zfs is AWESOME!!! Except that even Sun is not recommending we use it for zone root file systems until they hit update 6 of Solaris 10. Whoops! That's in November, so we're just sitting tight until they support Solaris root/OS zfs file systems. Then we upgrade. Then ? Then we profit!

Ob. Apple Joke referencing earlier /. artice:
Of course, the delay for the consumer OSX support of zfs will have to wait until they code in skipping backups of your iTunes library! ;)

Re:How will I benefit?

[Lally Singh]

Wow, it's such a major leap it's hard to describe.

Imagine having an external HDD on your mac. Whenever you plug it in, it automatically starts mirroring the internal drive.

Take atomic snapshots of your entire filesystem, send it over scp to back up your drive as a single file. Or, send over the difference between two snapshots as an incremental backup.

Have more than one drive, want mirroring? 2 steps on the command line.

Have a directory you really care about? Make it a sub-filesystem (this doesn't involve partitioning, etc, just a command that's almost identical in syntax and performance to mkdir) and tell ZFS to store 2 or 3 copies of it.

Have a directory you'd like auto-compressed? Tell zfs to compress it. New data to it is automatically, and transparently compressed. Completely transparent to the user and to applications.

And I'm just getting started. Trust me on this, google it.

Re:How will I benefit?

[MBCook]

For one thing it would make the implementation of Time Machine much simpler. No more directory tree full of hard links and such. If they put it on other boxes (like Time Capsule) they could unify the format (it uses a different storage method). Then you could pull the Time Capsule drive, stick it in your Mac, and be all set.

For servers, it has all the standard ZFS benefits (easy storage adding, redundancy, performance, etc).

For home users, it would let you simply plug a new drive in your Mac, press a button, and have it just add space to your main drive. You wouldn't need to specifically setup a RAID. No resizing. No "external drive" if you don't want it that way. Just buy a drive, plug it in, and it's all handled for you.

Re:How will I benefit?

[fishdan]

This is very informative

Re:How will I benefit?

[Lally Singh]

Yeah, self-reply. Some links on the matter:

ZFS: The last word on filesystems

Why ZFS for home

Why ZFS Rocks

ZFS: what "the ultimate file system" really means for your desktop -- in plain English!

Re:How will I benefit?

[Wesley Felter]

ZFS uses super-paranoidal checksumming which can detect drive problems in advance. No, checksumming cannot detect drive problems in advance; for that you need SMART. Once your drive has been corrupted ZFS will kick in and prevent you from accessing any corrupt data.

Re:How will I benefit?

[profplump]

What is it with you people and filesystem-level snapshots?

I'd much rather have volume or block level snapshots, like with LVM and other similar systems. Those systems provide RO and RW snapshots, dynamic partitioning, drive spanning, etc., and can be easily layered with other block-level components to provide compression, encryption, remote storage, etc. as well. All that without tying you to a single file system (though that may be a moot point on OS X, as it will only boot from HFS/HFS+ AFAIK).

If you really wanted to you could even write a script that takes no arguments other than a path name and automatically created a series of volumes of an appropriate size for the folder you selected, setup software raid to mirror them into a single device, mount the device with a compression filter, format it (with any file system) mount it normally, move the data over, drop the old data, rebind the mount point to the old path name, and update fstab. The only thing you miss here that ZFS may be able to do (I didn't check) is avoid closing the files that are moved.

I'm not saying the features ZFS has are useless -- I think they are great -- they just aren't all that new and exciting. They might be new OS X, or repackaged in a way that's easy to consume, but they are things that anyone with big disks has been doing for years.

Re:How will I benefit?

[Cyberax]

SMART sucks. That's just a fact - very often it kicks in when your drive has failed.

Also, there are lot of real cases where malfunctioning drive can silently write incorrect data. ZFS will help you in this case.

Re:How will I benefit?

[Lars512]

For home users, it would let you simply plug a new drive in your Mac, press a button, and have it just add space to your main drive. You wouldn't need to specifically setup a RAID. No resizing. No "external drive" if you don't want it that way. Just buy a drive, plug it in, and it's all handled for you.

I'm not sure you'd want it to work this way for external drives. Will they be available at crucial parts of boot time when some important files are striped across them? Even if they are, you're basically unable to ever remove the external drive again. If there's a problem with the drive, all your data is lost. Probably the way these drives work now is better. Maybe mirroring onto an external drive would work ok, but it would then be an undesirable write bottleneck.

Re:How will I benefit?

[MSG]

I'd much rather have volume or block level snapshots ... All that without tying you to a single file system

It is not possible to make consistent block-level snapshots without filesystem support. If your filesystem doesn't support snapshotting, it must be remounted read-only in order to take a consistent snapshot. This is true for all filesystems. When they are mounted read-write, there may be changes that are only partially written to disk, and creating a snapshot will save the filesystem in an inconsistent state. If you want to mount that filesystem, you'll need to repair it first.

Re:How will I benefit?

[The Blue Meanie]

For that to work, you need a boot loader that supports zfs. This will come first in Solaris 10 x86 because they already have grub there. It's easier.

Actually, GP was talking about ZONE root filesystems, which have absolutely nothing to do with the bootloader, since the zone runs on top of the underlying global zone. You CAN put a zone root on ZFS at the moment, but Sun neither recommends nor supports that setup.

For SPARC machines, it'll require new OpenBoot firmware that understands zfs.

And this is simply untrue, period, even for non-zone ZFS root filesystems. OpenBoot loads the next stage of boot code by reading raw data from blocks 1-8 of the chosen slice of the boot disk, and THAT is the code that needs to be able understand the filesystem that will be mounted as root (UFS, ZFS, or whatever). OpenBoot only needs to understand the disk label/partitioning and to be able to read the disk blocks. It already does that, so non-zone ZFS root will NOT require any modifications or upgrades to OpenBoot, just updates to the bootloader code that is written to the disk in blocks 1-8.

Re:How will I benefit?

[ArbitraryConstant]

I'd much rather have volume or block level snapshots, like with LVM and other similar systems. Those systems provide RO and RW snapshots, dynamic partitioning, drive spanning, etc., and can be easily layered with other block-level components to provide compression, encryption, remote storage, etc. as well. All that without tying you to a single file system (though that may be a moot point on OS X, as it will only boot from HFS/HFS+ AFAIK). ZFS shits all over LVM:

-Say I want to take hourly snapshots, and retain them for a month. When the parent data for a ZFS snapshot changes, ZFS merely has to leave the old data alone. OTOH, LVM must copy the block to every snapshot before it can change it in the parent. My hourly snapshots will quickly cause my disk to thrash to a halt with LVM and using much more space, while ZFS incurs a negligible penalty.

-LVMs allow dynamic partitioning, but they can't share capacity on the fly. If I delete a file on an LVM-hosted filesystem, that space becomes available to the filesystem but not all the others. Unless I shrink the filesystem, generally requiring that I take it offline for a while.

-Another layer could potentially handle checksums on LVMs, but in practice Linux can't do this properly by itself.

-ZFS can use other layers, there's just a substantial benefit to letting it run the show.

The only reason this won't turn out to be a huge disadvantage for Linux is that BTRFS will provide most of the same features. Layering can be a very helpful design tool, but there are times it becomes a hinderence. It's important to be flexible when there's benefits to integrating stuff into a single layer.

Re:How will I benefit?

[MrMacman2u]

Actually S.M.A.R.T. is an amazing tool and is utterly invaluable in monitoring drive health... IF and ONLY IF you have the appropriate software (windows: google it, *nix: smartmontools) AND know how to read the resulting output.

The reason many people think SMART sucks and I say to check SMART manually is because 95% of drive manufactures set the threshold or "fail" values WAAAAY too high or low!

I use SMART constantly (about once every other week) to "check in" on how healthy my drives are and knowing how to read the values the software returns has saved my data many times. In fact, due to certain SMART values, I KNOW my Thinkpad hd is on currently on it's way to failing even though it is still working fine, for the moment. The SMART information has let me know it's on it's way out the door and therefore I have taken precautions to safegaurd the data on that machine and have the drive replaced.

Granted, SMART can't inform you ahead of time about sudden and complete mechanical or electronic failure, it can warn you if your drive is slowly the kicking the bit bucket. (With a small amount of know how until drive manufactures wake up and set more appropriate values)

Don't knock something you know nothing about! Kthnxbye!

Re:How will I benefit?

[Cyberax]

Maybe I'm unlucky, but I had three notebook HDs die on me without any warning. Even though I'm using 'SmartMon' program which should warn me about worsening drive condition.

Also, Google's on hard drive survey seems to come to the same conclusion: "One of those we thought was most intriguing was that drives often needed replacement for issues that SMART drive status polling didn't or couldn't determine, and 56% of failed drives did not raise any significant SMART flags"

http://www.engadget.com/2007/02/18/massive-google-hard-drive-survey-turns-up-very-interesting-thing/

Re:How will I benefit?

[Fweeky]

SMART sometimes works, very often it doesn't. Manufacturers have been progressively crippling it, to the point at which some barely even monitor anything, because they're perceived by marketing as being bad for business.

e.g. Seagate are one of the few vendors who are honest about ECC correction and seek error rates, and their SMART counters are correspondingly huge and read rather poorly (50-60/100 is a common value); you can even graph them and see the rates sweep up and down as the drive moves the heads over the platters every hour or so. Nobody else does this, and occasionally you'll see someone on a forum asking if it means their disk is failing.

Raw read and seek error rate on my Western Digital drives? 0, corrected values: 200/200. Right, I'm sure WD have magical drive heads which read every bit perfectly every time, and never miss seeking to a track, ever.

That's not to say SMART can't be useful, but as Google's disk failures USENIX paper demonstrates, they're not as reliable as one might hope.

I dunno if I trust it yet.

[boxless]

I've lurked a bit in the opensolaris forums, and there's a whole bunch of scary things with this FS. Like the RAM requirements for starters.

Re:I dunno if I trust it yet.

[cblack]

RAM settings can be tuned down (see ARC cache sizing). If you've just lurked on a list and not run it or read the tuning docs, you don't know and your vage sense of it being "scary" should hold little weight. I will say that the defaults for ZFS on Solaris are geared towards large-memory machines where you can afford to give a gig to the filesystem layer for caching and such. I don't know the absolute minimum RAM requirements, but I doubt they are inflexible and "scary".
I've been running zfs on solaris oracle servers for a bit and it is REALLY NICE in my opinion. They have also continually improved the auto-tuning aspects so you don't even have to worry about some of the settings that were often tuned even two releases ago (10u2 vs 10u4).

Re:I dunno if I trust it yet.

[ApproachingLinux]

a good place to start is probably the ZFS Best Practices page. the google text cache of that page is here. beyond that, try to google "zfs ram requirements".

Re:I dunno if I trust it yet.

[MrMickS]

Solaris has used the idea of "unused memory is wasted memory" for a long time now. If memory isn't being used by applications then why not use it for file system buffering and cache? As long as it gets reaped by your memory manager when you need it for applications it seems like a good thing to do performance wise.

Re:Finaly

[Jellybob]

Our mail stores at work can fill 8TB quite happily (although they're on big network attached storage boxes, not ZFS).

Re:Finaly

[jandrese]

8TB is rapidly becoming "not that much stuff" these days. You can already buy 1TB HDDs, so we're just three doublings away from hitting the limit with a single drive (not to mention RAID arrays).

possible use

[MonoSynth]

The ability to hibernate your Mac with 16TB of RAM :)

More efficient backups.

[pavon]

One feature of ZFS is copy-on-write file snapshots, which allow you to "copy" a file, but the common portions of the file will be shared between the two copies, decreasing disk space.

This is great for backing up large files containing frequent but small changes. For example encrypted disk-images, parallels windows disk images, database files, the Entourage email box, or home videos you are in the process of editing etc.

Right now Time Machine creates an entire copy of the file each time it changes, making it unsuitable for backing up these types of files, and so you are encourage to exclude those files from backup. ZFS could fix that.

It could also make adding disk space more seamless, if desired. Slap on an external Firewire drive or even airport, click the "Add to storage pool button", and suddenly it just acts like part of your system drive. You don't have to worry about what is stored where.

Re:Indeed.

[Wesley Felter]

Anyone know how many drives can fail at once in a RAID-Z2 before you are 100% SOL? RAID-Z2 can survive two drive failures; three failures will kill the pool.

Re:Finaly

[grub]

We can finaly fill up more than 8 TB on this FS. Anyone up to try?(with what?)

Rookie. My swap space is 8 TB.

Re:"All features on this page are subject to chang

[QuantumRiff]

WinFS is almost ready... Its going to be here any day now. I heard its the base storage layer for Duke Nukem Forever!

Standardizing file systems

[failedlogic]

I don't know a whole heck of a lot of the technical details on ZFS. What I have read and understood, it sounds like what ZFS offers is something that every OS should include in its file system. Since, as I understand the BSDs and many Linux distros are starting to include (albeit limited/beta/alpha) ZFS support, and the long-rumored OS X inclusion being confirmed, could this be a universal file system for Operating systems? I would definitely like to see ZFS as a bootable Windows file system.

Say I have a portable USB hard drive or a dead motherboard in one system and want to retrieve the data off a hard drive. One computer has Windows and the other is Nix or OSX. Generally, the file system one could use that *should* work between Windows, Mac and 'Nix was Fat32. There are some issues with FAT32, the least of which is lack of support for large hard drives. The only other ways I can think of transferring the data are via Network or using a OS hook to read the data.

I just switched from Apple to Windows. I've been using an app to read my HFS+ file system on Windows to get data off the hard drive. It works well, but its not build-in. Nor is read/write NTFS access in other OSes. In any case, getting the data has been a bit of a pain. A standard file system I can just plug in a drive no problem would be awesome.

Re:Standardizing file systems

[larry bagina]

1. The GPL prevents ZFS integration (without a complete and total reimplementation of all the code... which won't happen since everybody prefers to write their own filesystem)
2. MS DOS/FAT is the universal file system for operating systems.

Re:Finaly

[Daswolfen]

n00b... ... my pr0n folder is 8 TB.

Re:Finaly

[Captain Splendid]

You're the noob! With 8TB of frigging swap, GP's porn stash can obviously only be counted in Libraries of Congress!

Re:Finaly

[jabuzz]

News to me, double checking the Sun pages tells me that two or more servers cannot mount the same pool at the same time. It is allegedly coming with Luster 1.8, but it ain't here now.

Re:Finaly

[sammy baby]

Lamer. 8 TB isn't enough to hold my collection of midget furry porn, let alone the whole shebang.

No, license issues

[bill_mcgonigle]

will it be available on Debian(Ubuntu) soon?

Not until OpenSolaris and Linux are both GPLv3.

ZFS is patented and patent protection is only conferred through use of CDDL'ed code, which isn't compatible with GPLv2. A cleanroom implementation of ZFS, besides being redundant, has no license to use ZFS's patented technology. Whether Sun would sue a linux dev over this is a separate issue.

BSD implemented a Solaris compatibility layer to use the CDDL code directly, but their license isn't incompatible.

Jeff and Linus have visited lately - I think Jeff was just helping him hook up a new gas grill, but maybe something work-related was discussed. :)

Re:No, I am understanding just fine.

[gutter]

It is pretty hard to tell from your tirades whether you are talking about the ability to support pluggable filesystems, or the availability of those pluggable filesystems. You seem to be conflating the two. You start by complaining that OS X lacks the ability to support pluggable systems, but the first link from the AC's post proves you wrong:

http://developer.apple.com/qa/qa2001/qa1242.html

In fact, every filesystem OS X supports is written using this mechanism, out of the box:

[gutro:~/] gutter% ls -1 /System/Library/Filesystems/
AppleShare
URLMount
afpfs.fs
cd9660.fs
cddafs.fs
ftp.fs
hfs.fs
msdos.fs
nfs.fs
ntfs.fs
smbfs.fs
udf.fs
ufs.fs
webdav.fs
zfs.fs

Your most recent tirade seems to be a complaint about the lack of available filesystems, which I guess is a reasonable complaint, but that's not what you orignally asked for. Then you asked for a simple package you could download and install, and again, the original reply contained one (MacFUSE). Granted, that's a poor example, because it hides OS X's native pluggable FS support behind the FUSE pluggable FS support, but that doesn't mean that the AC was wrong. You can go and download the MacFUSE package, and the sshfs package, install them using the standard installer, and begin using a filesystem that works over SSH, no compiling necessary. (Incidentally, that one is super handy).

In short, the original reply by the AC was 100% correct, and you were 100% wrong, (and seemingly unable to comprehend his reasonable explanations) and somehow by sheer bluster, you seem to have convinced everyone of the opposite.

Re:ZFS is fast, but not lightweight

[OrangeTide]

hehe.. very funny, WAFL is what is used in NetApp filers. You can read the patents on it and get a pretty good high level idea of how it works, the patent documents lays it out in pretty easy to understand terms. As for the mystery filesystem (starts with a D), it's like XFS but has more features to make it worth comparing to ZFS. The performance is similar to XFS too (a little better when it can hold transactions in NVRAM).

Even XFS is on par with ZFS (with lower cpu utilization) for nonclustered performance. XFS is so close to the theoretical maximum performance of a raw unclustered disk group (when tuned for the workload) that there is no "an order of magnitude or more" in those cases. When get get 99.5% of the raw disk I/O performance you're not going to reach an order of magnitude by making it .5% faster :)

Of course for a distributed cluster of disks the free version of XFS is nothing compared to ZFS, because XFS can't even really do clustering. And few people benchmark SGI's commerical CXFS, despite my experience with XFS even I haven't used CXFS.

Also it's hard to compare most filesystems to ZFS because most filesystems that have RAID just live on top of a hardware/software RAID implementation. XFS (and others) do a little bit of optimizations when they are on a RAID, but it doesn't really reflect in the performance numbers in a major way. ZFS has the advantage of RAID-Z, which is faster(usually) and far more flexible.

ps - I like to think of XFS as the base line of what a good filesystem should be, and you're either better than XFS or worse. I'm not trying to claim XFS is the fastest filesystem in the world or anything. Although if tuned for your workload the performance is quite impressive, when not tuned there is a lot of head scratching why all your RAM is gone and your performance is worse than FAT.