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

8 of 178 comments (clear)

  1. What does this mean for 'client'? by daveschroeder · · Score: 4, Insightful

    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.

  2. Re:Finaly by jandrese · · Score: 4, Insightful

    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.
  3. Re:How will I benefit? by fishdan · · Score: 3, Insightful
    --
    Nothing great was ever achieved without enthusiasm
  4. Re:How will I benefit? by profplump · · Score: 4, Insightful

    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.

  5. Re:How will I benefit? by Cyberax · · Score: 3, Insightful

    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.

  6. Re:How will I benefit? by Lars512 · · Score: 3, Insightful

    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.

  7. Re:Standardizing file systems by larry+bagina · · Score: 3, Insightful
    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.
    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  8. Re:No, I am understanding just fine. by gutter · · Score: 3, Insightful

    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.

    --
    Check out DRM-free movies at http://www.bside.com