Slashdot Mirror
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?"
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.
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
Tibbon
tibbon.com
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).
I read the internet for the articles.
The ability to hibernate your Mac with 16TB of RAM :)
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).
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!
/. artice: ;)
Ob. Apple Joke referencing earlier
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!
This is the NSA, we're gonna geet U h@x0r5! Also, what is a h@x0r5?
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.
Care about electronic freedom? Consider donating to the EFF!
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".
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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!
Care about electronic freedom? Consider donating to the EFF!
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.
WinFS is almost ready... Its going to be here any day now. I heard its the base storage layer for Duke Nukem Forever!
What are we going to do tonight Brain?
n00b... ... my pr0n folder is 8 TB.
Don't rush me, Sonny. You rush a miracle man, you get rotten miracles.
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.
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.
"I feel that if a person can't communicate, the very least he can do is to shut up." -- Tom Lehrer
-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.
I rarely criticize things I don't care about.