Slashdot Mirror


ZFS Shows Up in New Leopard Build

Udo Schmitz writes "As a follow-up to rumours from May this year, World of Apple has a screenshot showing Sun's Zettabyte File System in "the most recent Build of Mac OS X 10.5 Leopard". Though I still wonder: If it is not meant to replace HFS+, could there be any other reasons to support ZFS?"

63 of 351 comments (clear)

  1. Zettabyte? by bigtomrodney · · Score: 3, Informative

    Isn't the term 'Zettabyte File System' actually inaccurate now? I thought they dropped that and ZFS now only remains as a pseudo initialism

    --
    I never get used to these constant resurrections
  2. Exciting! by statusbar · · Score: 4, Interesting

    Now that Vista is finalized, expect Apple to show more and more of the 'secret' features of leopard!

    --jeffk++

    --
    ipv6 is my vpn
  3. Otherwise... by DrYak · · Score: 5, Funny
    Now that Vista is finalized,

    Because if Apple showed them before, there was a risk that Microsoft tried to announce them as future features in their soon-to-be-released perfect Windows Vista ?
    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
    1. Re:Otherwise... by statusbar · · Score: 4, Funny

      Nah, Microsoft would never do anything like that... They are a respectable company that does not misrepresent their products.

      --jeffk++

      --
      ipv6 is my vpn
    2. Re:Otherwise... by Sancho · · Score: 2, Insightful

      That said, there's zero chance (IMO) that Microsoft would add ZFS to Vista. They already dropped their transaction-based filesystem in order to get Vista out the door this decade. Adding ZFS support (much less using it as the default or recommended FS) would simply take too long, even if Apple had announced support a year ago.

  4. copy-on-write by Mr2cents · · Score: 3, Insightful
    FTA:

    Makes use of copy-on-write; rather than overwriting old data with new data, it writes new data to a new location and then overwrites the pointer to the old data Wouldn't that pose a problem for mmap?
    --
    "It's too bad that stupidity isn't painful." - Anton LaVey
    1. Re:copy-on-write by MotownAvi · · Score: 2, Informative

      Why? In today's world, writing to an mmap-ed file most certainly doesn't hit the disk for each write. Instead, a block of memory from the buffer cache is used to hold the changes. The only difference is that instead of being backed (VM-wise) by the swap file, the block is backed by the mmap-ed file.

      There's no real change here for ZFS, and it's unlikely that anything at the memory cache level even knows about the copy-on-write-ness of ZFS (or even cares).

      a

    2. Re:copy-on-write by TheRaven64 · · Score: 4, Interesting
      No. Mmap lives above the filesystem layer. Unless you are doing mmap on the block device, in which case you should realise that not everyone works for oracle...

      Mmap simple maps pages of a disk file into memory. If the disk file changes its physical location then the mapping is updated. When you call mmap, you give it a disk file, an offset, and an extent. It is up to the VFS layer to translate this into physical mappings. LFS has the same issues, and these were solved well over a decade ago.

      If you invoke mmap with MAP_PRIVATE, this actually makes it easier; if someone else updates the file then you just keep the existing mapping.

      --
      I am TheRaven on Soylent News
    3. Re:copy-on-write by Midnight+Thunder · · Score: 4, Interesting
      FTA:

      Makes use of copy-on-write; rather than overwriting old data with new data, it writes new data to a new location and then overwrites the pointer to the old data

      Wouldn't that pose a problem for mmap?


      It may do, but like many things there are alternative approaches.

      From working on embedded hardware with flash memory, this makes me wonder whether possible addition of ZFS is meant to be for flash storage? Let me explain: flash memory has a fairly limited write-count, relative to hard disks, so to compensate for this memory is written in a circular fashion, to ensure that a given sector is written the least often possible. In addition to this, from what I can tell, Apple's main sales point are low profile computers and portables. The latter would benefit from flash storage as means of extending battery life, even if it is for a certain elements, such as for the OS which is accesed far more frequently than anything else on disk. Given this I wouldn't be surprised to see flash memory in future models of Apple portables, using ZFS, while HFS+ is still used for the hard disks.

      This is pure speculation, but I feel that it has a high probabilty of being near the mark.
      --
      Jumpstart the tartan drive.
    4. Re:copy-on-write by multipartmixed · · Score: 2, Informative

      Right.

      Similar issues exist without problems when mmap()ing files from NFS. You cannot update just a few bytes with NFS, you have to write the whole disk block out.

      I'm fairly confident that the current "standard" way to implement mmap at the moment is to update the pages, mark them dirty, and let the VM subsystem write them to disk.

      I haven't had to look at mmap's implementation in a long time, though.. but IIRC Rich Teer and/or Adrian Crocroft had good articles about it a few years back.

      Obviously, I arrive at this problem space with a huge Solaris influence. But this is a well-understood problem, and I don't think Sun's implementation is particularly revolutionary.

      --

      Do daemons dream of electric sleep()?
    5. Re:copy-on-write by Anonymous Coward · · Score: 2, Informative

      Er.. a copy of the modified data is saved to a new location, as opposed to overwriting the original data, which is exactly what happens with COW memory pages in VMM's too. Sounds more like NetApp just like using a slightly different term to make them sound different :P

    6. Re:copy-on-write by caseih · · Score: 2, Informative

      ZFS currently wouldn't work very well for flash storage systems under a certain size because of initial overhead. ZFS requires each device to be at least 64 MB in order to be added to a pool. Also the minimal overhead of ZFS is 32 MB. In other words if you take a 64 MB disk, format it to ZFS, you'll only have 32 MB of space available. As you add devices to the pool, this overhead grows, but at a pretty small rate.

  5. Re:ZFS would be cool by Anonymous Coward · · Score: 2, Informative

    That would be nice, but since ZFS can't be used as boot partition even in Solaris (they'll fix it). it's better to let it stabilize a couple of releases (ZFS is a young FS even in Solaris, after all) and then switch.

  6. What a moron by Anonymous Coward · · Score: 2, Insightful

    "Though I still wonder: If it is not meant to replace HFS+, could there be any other reasons to support ZFS?"

    Duh... It's called compatibility.

    1. Re:What a moron by Udo+Schmitz · · Score: 4, Insightful
      It's called compatibility.

      Wouldn't full NTFS support (or well, support for any FS more in use then ZFS today) make more sense?
    2. Re:What a moron by metamatic · · Score: 5, Insightful
      Wouldn't full NTFS support (or well, support for any FS more in use then ZFS today) make more sense?

      Yeah, I mean it's not like NTFS is defined and controlled by an organization renowned for its hostility to other platforms, reluctant to document things in a way that other people can implement them, and scared of interoperability, is it?

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    3. Re:What a moron by AcidLacedPenguiN · · Score: 2, Funny

      my knoppix disc cries when I try that. It didn't before, but now it's just an emo jerk.

      --
      disclaimer: I've been known to store numbers in my ass for which to dig out when quantities are required.
    4. Re:What a moron by iPaul · · Score: 4, Informative

      You both miss the point of HFS+ and ZFS. In Solaris ZFS has not replaced UFS. ZFS is an elegant way to manage large amounts of storage tied together with inexpensive and simple SATA drives. If you have one disk in your Mac, ZFS probably will not be your choice. HFS+ will work very well and be very easy to manage. A file server with 3 or 4 750 GB drives however, might be cut up so that part of the storage is mirrored for safety, limited for certain uses, and spanned over drives for size. For example, 3 750's could be divided into 1 TB unmirrored storage, 250 GB mirrored, a temp area of up to 100GB and the rest (650+ GB depending on temp are usage) held in reserve. In addition ZFS does quite a bit of error checking on the data to avoid any possible corruption during reads. However, it will never replace HFS+ on an iMac for your average user.

      --
      Leave the gun, take the cannoli -- Clemenza, The Godfather
  7. Re:Reason to support ZFS... by Boghog · · Score: 3, Informative
  8. Reasons to support? Servers by ShyGuy91284 · · Score: 5, Interesting

    I will be soon converting my Linux server to Solaris just for ZFS. Although ZFS may not terribly useful on a normal desktop, on a server, it's very powerful.... The idea of parity data actually being used actively to ensure data isn't corrupted is brilliant imho. So is the idea of on-the-fly recovery (I remember a video of some guy writing 30 megs of junk to a partition using dd, ZFS detecting it, and repairing it). *ends rant since all this can be read up about online*

    --
    In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
  9. For some reason... by uohcicds · · Score: 2, Interesting

    ...the words "Time Machine" are jumping up and down in front of my face trying to attract my attention. I can't think why that might be.

    --
    It's not you: I'm just this horrifically socially awkward with everybody.
    1. Re:For some reason... by Coward+the+Anonymous · · Score: 2, Funny

      You also need 1.21 gigawatts of power.

      --
      -- Jason
  10. Not a likely replacement... by qwertphobia · · Score: 4, Insightful

    If it is not meant to replace HFS+, could there be any other reasons to support ZFS?" Well, OSX 10.4 already supports FAT16, FAT32, and HFS, HFS+ (case sensitive and case-insensitive) and UFS. I don't see any obvuious conclusion that HFS+ is on the way out. Now if the OSX kernel AND os both support a ZFS-formatted partition as a boot partition, we might find it as an accceptable replacement, but otherwise I would think ZFS will be added for large enterprise SAN RAIDs and such.
    --
    Never ask for directions from a two-headed tourist! -Big Bird
    1. Re:Not a likely replacement... by larkost · · Score: 2, Insightful

      Actually, if you are using UFS on any platform for "compatibility", then "sucks to be you". NeXT's/Apple's version may be a little farther out than other implementations, but UFS in general suffers from many mutually incompatible variants. In fact it is better to assume that any compatibility is purely accidental, you will have a better expectation level that way.

  11. Obligatory by value_added · · Score: 3, Informative

    A clicky to the Wiki article on ZFS.

  12. ZFS is overkill for a laptop - for now by TheRaven64 · · Score: 4, Interesting
    A few years ago, I sat down and worked out exactly what I thought a filesystem should do, and how I would implement it. At the time no filesystem came close. Then Sun released ZFS. Real documentation on it is hard to find (behind the marketing hype), but when I did track it down I discovered two things:
    1. They had implemented everything I thought they should, and
    2. That only accounted for about 40% of the features of ZFS.
    Calling it the last word in filesystems might be hyperbole, but I expect ZFS to last a good 10-20 years, which is quite respectable for a filesystem, and I wouldn't be surprised if it lasted longer. Is it a replacement for HFS+? Not yet.

    HFS+ is a very nice filesystem for single user systems with a single disk. It implements journalling, has reasonable performance, and has good metadata support. For the average users at the moment, the only real advantage of ZFS would be snapshots, and these are not too difficult to implement for other filesystems.

    ZFS, however, is much better when you have multiple physical disks. At the moment, only the top-end Macs have more than one disk. This is likely to change in two ways:

    1. Cheap flash,
    2. Network storage
    For a home user, ZFS could handle backups trivially by plugging in a large flash drive and adding it to the pool. I suspect this will be one mechanism Time Machine will use. Due to the way ZFS works, you can just mirror a part of the directory tree (e.g. /Users/aUser) onto the external disk. With a big external drive, you could mirror the entire disk onto it and also save snapshots (another Time Machine feature...). The same could be done with network storage. With the current price of hard drives, I wouldn't be surprised if .Mac started offering 10-20GB of storage space for remote backups using this mechanism (take a look at the NFS4 integration in ZFS to see how this could be done).

    ZFS is not needed as a replacement for HFS+ in 2007, but it probably will be in 2008-9. ZFS is a 128-bit filesystem, which means it is designed to last for a long time. We will probably never need a 128-bit filesystem (unless we actually want to build hard drives the size of planets with single-atom sectors), but we will need a 65-bit filesystem once we get to around 10 Exabytes. This won't happen with single drives for a while, but it will with RAID arrays.

    --
    I am TheRaven on Soylent News
  13. ZFS vs HFS vs NTFS? by Bonker · · Score: 5, Insightful

    The tech behind ZFS at least sounds very impressive, but I have to wonder how useful it is for workstation drives.

    I've never found plain-Jane posix permissions to be all that useful on anything other than the most basic of server environments.

    HFS has going for it all the fun stuff we've come to love apple for, such as transparent file customization like icons, labels, meta data, and whatnot through resource forks. I assume that these can be made to work with ZFS by making hidden files.

    What I'd really like to see is both that kind of functionality along with NTFS's really excellent ACL permission system implemented. ACL permissions are a godsend for people responsible for running a file store that's used by humans as opposed to automated processes. NTFS also has a great deal of capacity for meta-data, although not to the same level as HFS.

    NTFS is one of the few worthwhile things that's ever come out of Redmond. I wish more people would spend a bit learning from it without throwing it away simply because it's MS bloat.

    --
    The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
    1. Re:ZFS vs HFS vs NTFS? by pesc · · Score: 5, Insightful

      NTFS is one of the few worthwhile things that's ever come out of Redmond. I wish more people would spend a bit learning from it without throwing it away simply because it's MS bloat.

      I wish MS would let us. NTFS is worthless if you don't run Windows. And it hinders interoperability with other systems because its implementation and disk layout is secret/patented.

      Why, do you think, there is no stable implementation that can write NTFS volumes (other than the MS implementation)?

      Contrast this with ZFS which is released under an open source license.

      --

      )9TSS
    2. Re:ZFS vs HFS vs NTFS? by UtucXul · · Score: 4, Insightful
      NTFS is one of the few worthwhile things that's ever come out of Redmond. I wish more people would spend a bit learning from it without throwing it away simply because it's MS bloat.
      I think the negative opinion some people (including me) have of NTFS come not directly because it is from MS, but come from the incompatibility with everything else. I can't (reliably) read/write to it from a Mac, Linux, or Sun. That leaves only people totally in the MS camp able to use it. It may have some nice technical features, but I can't ever see them, so it is a little hard to be impressed or care about them too much.
    3. Re:ZFS vs HFS vs NTFS? by pesc · · Score: 4, Informative

      I've never found plain-Jane posix permissions to be all that useful on anything other than the most basic of server environments. ...
      What I'd really like to see is both that kind of functionality along with NTFS's really excellent ACL permission system implemented.


      I wish you could read more about ZFS before suggesting how you could improve it by adding ACLs. It already supports them!

      http://blogs.sun.com/marks/entry/zfs_acls

      --

      )9TSS
    4. Re:ZFS vs HFS vs NTFS? by More+Trouble · · Score: 4, Insightful
      HFS has going for it all the fun stuff we've come to love apple for, such as transparent file customization like icons, labels, meta data, and whatnot through resource forks. I assume that these can be made to work with ZFS by making hidden files.

      You assume correctly, since most of that business is taken care of with Bundles. This is why it more or less works on UFS, which is already supported on Mac OS X, and has been for years. Forks & whatnot are really a legacy idea.

      What I'd really like to see is both that kind of functionality along with NTFS's really excellent ACL permission system implemented.

      That's funny! The HFS+ ACL system is Microsoft's ACL system, much to the chagrin of the Unix community.

      :w
    5. Re:ZFS vs HFS vs NTFS? by orgchartleafnode · · Score: 3, Interesting
      What I'd really like to see is both that kind of functionality along with NTFS's really excellent ACL permission system implemented.

      Mac OS X Server 10.4 (Tiger) already has this. See: http://www.apple.com/server/macosx/fileprint.html

      There is a "File Services" white paper linked off of he above page but here is the relavant marketing:

      New in Mac OS X Server v10.4 are access control lists (ACLs), providing flexible file system permissions that are fully compatible with Windows Server 2003 Active Directory environments and Windows XP clients.
    6. Re:ZFS vs HFS vs NTFS? by Circuit+Breaker · · Score: 3, Informative

      A deadline scheduler (a-la ZFS) is wonderful when multitasking disk heavy apps. That does not happen too often on a laptop (or a desktop, for that matter), but I've had Windows (and on rare occasions, even Linux) work horribly under such load. ZFS' "worst case behaviour" is supposed to be significantly better than any other system in use today.

      NTFS's ACL system is horrible. While it has a lot of descriptive power, it's a pain to manage, the result being that it is almost never used. The old Unix model, while simple, is easy to manage, and as a result is often set up reasonably. Novell's "Trustees" model works much better than either, but for some reason it wasn't adopted by others.

      NTFS is slow and inefficient, fragments horribly, and lacks fundamental features such as proper symlinks (and only supports directory hardlinks). It has a reasonable journal implementation, and it supported large files before other systems did, but it's very outdated and does not compare favourably with any of the modern high performance file systems.

  14. It's to support Time Machine by FunWithHeadlines · · Score: 4, Interesting
    See this Ars Technica article where John Siracusa said back in August:
    "For Mac geeks of a certain persuasion, the first mention of a soon-to-be-revealed feature of Leopard during the WWDC keynote set off a mental chain-reaction. That feature was Time Machine, and the name alone was enough to cause one particular phrase to hammer in the mind of many people, including me: "New file system in Leopard!" It was even a bingo square. In fact, it was my personal favorite bingo square, and the one that I most looked forward to marking.

    But let's back up a bit. Why should the mere name "Time Machine" scream "new file system" to anyone? And why the excitement about a new file system in the first place? What's wrong with HFS+, Mac OS X's current file system? It's got journaling. It supports arbitrarily extensible metadata. It can even be case-sensitive to satisfy the Unix geeks. Does Mac OS X really need a new file system?

    In a word, yes. HFS was a state-of-the-art personal computer file system when it was first released...twenty-one years ago. HFS+ is only eight years old, but it's built on many of the design decisions of HFS. Progress marches on. Today, there are new capabilities that the best modern file systems have, but that HFS+, even with all of its recent additions, does not. Here's a short list.

    • Efficient storage and handling of very small files.
    • Logical volume management through a pooled storage model.
    • Improved data integrity using checksums on all data.
    • Snapshots.

    So it's about the snapshot ability of ZFS, and that's exactly what will be needed for Time Machine.

  15. Re:Just to get it out of the way... by 0racle · · Score: 4, Informative
    Since we're nitpicking:
    The letter "Z" is properly pronounced "Zee" in the USA and Iraq (after 2003)
    That would correctly read "The letter "Z" is improperly pronounced "Zee" in the USA and Iraq (after 2003)"
    --
    "I use a Mac because I'm just better than you are."
  16. ZFS + Timemachine by jbolden · · Score: 2, Interesting

    With ZFS we might be able to get some very powerful backup features into OSX. Most binaries files don't change most of their content, ZFS makes it possible to due meaningful differential backups on large binary files. So for example 200 versions of a word doc with sounds and pictures that got revised over 6 months get stored in maybe 3x the space of the last revision. Emails with the same attachments get stored in just a few k rather than taking a meg each.... If Apple has this all working together by 10.5 then TimeMachine will work far far better then people currently expect it to. A 50g drive will be backing up a terabyte of worth of files.

  17. What? Of course it is by masklinn · · Score: 2, Interesting

    if it is not meant to replace HFS+, could there be any other reasons to support ZFS?

    The answer is that it probably is meant to replace HFS+, but since ZFS is not bootable yet (including for Solaris 10) Apple can take the time to introduce ZFS, build tools for easier management, and let people get familiar with the FS before they have to drop HFS+.

    HFS' lifetime has already stretched far beyond what it should have, it's time for Apple to think of its next generation FS, and ZFS is an extremely promising FS with heaps of amazing features Apple has already started to integrate into its UIs with Leopard (Time Machine + ZFS Snapshots anyone?).

    ZFS also shows strong promises as both a home and a server FS.

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  18. Re:ZFS would be cool by furry_wookie · · Score: 2, Informative

    Actually, you CAN use ZFS for everything except boot...so all you need is a tiny little grub boot partition and your golden. This is a tried and true method of booting NIXen with other filesystem formats.

    --
    -- Given enough time and money, Microsoft will eventualy invent UNIX.
  19. They already have UFS, and don't use it... by argent · · Score: 2, Interesting

    They already have UFS and don't make it really usable, even after making a big deal about it being updated to the latest version from FreeBSD in Panther. It's a shame, too, because while HFS+ has a lot of nifty features all of them could be emulated over UFS or ZFS or any other file system (by putting the hooks for applications like Spotlight in the vnode layer rather than the file system - the vnode layer already has most of the hooks Spotlight needs), it falls far behind UFS in terms of reliability.

    In fact HFS+ is *so* bad that if it wasn't for a couple of apps that absolutely freak out if they don't have their pet un-emulated feature I would have gone to UFS long since... even if I lost Spotlight completely. Until my Mac I had never run into a file system that wasn't so badly damaged as to be unbootable that coudn't be repaired by fsck... but apparently with HFS+ just running it "too full" can trash it, and I lost my system disk on my old G4 three months running because of that!

    So I wouldn't hold out any expectations of ZFS being implemented in any useful way. They already have better file systems than HFS+ and they're not using them.

  20. Re:Just to get it out of the way... by gb506 · · Score: 4, Funny

    Zed's dead, baby.

  21. Re:Just to get it out of the way... by clarkcox3 · · Score: 3, Informative
    Actually 'Zed' is probably closer to the source from which it comes - the Greek letter 'zeta'
    ... and "Bed" is closer than "Bee" to "Beta", yet everyone says "Bee". At least the American pronunciation of the alphabet is internally consistent. ;)
    --
    There are no tiger attacks in my area and it's all because this rock I'm holding keeps the tigers away.
  22. ...so how does one define "capacity" therein? by cyclomedia · · Score: 4, Interesting

    I've been wandering about this and am insanely curious: if ZFS really does intelligently copy on write how far can it take it?

    for starters, does the FS "know" that i've just clicked "Save As" in my word processor? what about copy and pasting a file back into the same directory to make a local copy? Also? is it just within variations on the same file? if i have a particular setup exe on my system but forget, and download it again to the desktop surely the FS has no initial way of knowing that they are one and the same, does some funky heuristic happen?

    basically: does the OS's read/write/copy/delete functionality have to invoke copy-on-write via a FS API or is it built in for every single sector-sized chunk that gets stuffed into the FS?

    the next question is the one in my subject: how therefore do you define "capacity"? if i've got a bunch of files that take up 700mb on a ZFS device and try to back up to a (Joliet) CD will i get a message telling me that the CD doesnt have room? i can imagine this scenario being unlikely with optimised binary data (jpegs and mpegs) but if i'm backing up a dev environment with autobackups (main.c,main.c.bak.001,main.c.bak.002,etc.) and manually created and dated directory tree "snapshots" (dev,dev_backup_2006-12-18,dev_backup_2006-12-01,e tc.) then this could probably happen quite easily.

    --
    If you don't risk failure you don't risk success.
    1. Re:...so how does one define "capacity" therein? by jbolden · · Score: 3, Informative

      does some funky heuristic happen?

      Yes, I used something similar to ZFS for mass document storage a few years back. You do a complex checksum on the block level. Any two blocks with the same sum are the same. Each unique block is only stored once, though multiple files might link to it. You're right the file system doesn't know why you are using the same blocks over and over, but it doesn't care.

      if i've got a bunch of files that take up 700mb on a ZFS device and try to back up to a (Joliet) CD will i get a message telling me that the CD doesnt have room?

      Assuming you have repetitive block, yes.

  23. Send/receive useful for .mac sorts of features by csoto · · Score: 3, Interesting

    I can imagine that using zfs send/receive to export/import pools would be an extremely efficient/safe method of replicating data. Perhaps some sort of ".mac mirror" could work. This would make Time Machine exceptionally useful, and I'd definitely commit extra $ for .mac services (if reasonable) for this.

    --
    There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
  24. Re:ZFS would be cool by multipartmixed · · Score: 2, Funny

    Whatabout sun cluster 3? I particular, for the global filesystem?

    Last I looked, they said, "NO! NO ZFS! IF YOU TRY, THE MOONS OF URANUS WILL CRASH INTO PLUTO!"

    --

    Do daemons dream of electric sleep()?
  25. Re:Reasons to support? Servers by kestasjk · · Score: 3, Insightful

    It sounds good, but I think migrating for it just a tad extreme given that it will be implemented for Linux pretty quickly. We're talking about neat new features here, it'll re-enforce or make easier backups and redundancy, but it's not a to-die-for solution that will solve all your problems. There's no way I'd drop a fully configured server installation which does what I need for a new filesystem.

    By the way it's nice to see dtrace, open source Java, and now ZFS coming out of Sun recently. I almost feel sorry for how little they get out of a lot of their innovations, they remind me of Bell Labs just before they died.

    --
    // MD_Update(&m,buf,j);
  26. Re:going for Linux incompatibility, it seems by Bralkein · · Score: 2, Interesting
    Yes, that's the typical Apple solution: you can sort of use it, but if you really want to use it, you have to commit to using OS X. It's not a good proposition.
    Well, I would think that if you were going to move from Linux to an OS which supports ZFS, you would move to Solaris.

    I seriously doubt there will be an independent implementation of ZFS; that work would probably go into ext5. Even if there were (or if ZFS becomes GPL compatible), I doubt it will get much traction: Linux has had more powerful file systems than ext3 for many years, and people choose not to use them. Impressive feature lists don't make a better file system.
    I agree that ext3 isn't the best thing out there for Linux, and I don't even use it myself. However, I would suggest that the reason for so many people still using ext3 is that most other filesystems aren't better enough to encourage people to move away from ext3. Look at some of the posts under this story - you will find stories of people moving from Linux to Solaris, really just because they want the features of ZFS. There is demand for ZFS in the Linux kernel, and if it becomes a common filesystem on OSX, I predict the demand will only increase. I don't expect ext4 will satisfy this demand, either.
  27. Secure Delete? by HTH+NE1 · · Score: 3, Insightful

    Wouldn't that pose a problem for mmap?

    I think it would pose a problem for secure deletes. Try to obliterate a file by overwriting it with garbage, you end up writing somewhere else instead? Would the next overwrite attempt get the original location or would you have to write enough garbage to cycle over all the free space of the volume? Considering how large these volumes can get, that's a lot of boiled oceans for a multi-pass secure delete.

    --
    Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
    1. Re:Secure Delete? by HTH+NE1 · · Score: 2, Insightful

      One, transparent encryption is still under development for ZFS, and two, encryption is only good for data that needs to be confidential in the relatively short term. Anything for which you really need total deniability in perpetuity, encryption is insufficient to protect you.

      --
      Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
    2. Re:Secure Delete? by blank+axolotl · · Score: 2, Interesting
      Well, according to the manual page for 'shred', you can't do that reliably on ANY filesystems such as
      • log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
      • filesystems that write redundant data and carry on even if some writes fail, such as RAID-based filesystems
      • filesystems that make snapshots, such as Network Appliance's NFS server
      • filesystems that cache in temporary locations, such as NFS version 3 clients
      • compressed filesystems

      So in other words you can't reliably delete a file on many modern filesystems anyway (unless there are more advanced programs than shred?), and ZFS is no different. I think that melting your hard drive is the suggested solution.
  28. Re:Reasons to support? Servers by NatasRevol · · Score: 2, Informative
    --
    There are two types of people in the world: Those who crave closure
  29. Re:Reason to support ZFS... by shawnce · · Score: 2, Informative

    I doubt Apple is going to require ZFS for Time Machine anytime soon. I fully expect HFS+ to continue to be the default file system for Mac OS X for a while (years). I believe ZFS support in Mac OS X is solely for the high-end / server space of the customer spectrum.

  30. Re:Reasons to support? Servers by xehonk · · Score: 2, Interesting

    I wish that was the case. I really don't want to set up my linux root partition on fuse.
    "Porting ZFS to Linux is complicated by incompatibilities between CDDL, the license its source is released under, and GPL, the license which governs the Linux kernel. To work around this problem the Google Summer of Code program is sponsoring a port of ZFS to Linux's FUSE system[10] so the filesystem will run in userspace instead. However, running a file system outside the kernel on Linux has significant perfomance impact." (from http://en.wikipedia.org/w/index.php?title=ZFS&oldi d=95110224#Platforms)

  31. Re:Storeage size - speak for yourself by bar-agent · · Score: 5, Funny

    "That's no moon -- that's a file server!"

    --
    i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
  32. Re:Reasons to support? Servers by anaesthetica · · Score: 2, Insightful

    Indeed, we may see Mac OS X Server supporting default ZFS before Mac OS X proper. It would make sense to deploy it first in a limited market with technical expert users as your target market.

  33. Re:Reasons to support? Servers by Sparohok · · Score: 3, Informative

    Hard drives silently losing data is a problem solved by RAID.

    That is profoundly wrong. Vanilla RAID will not discover and cannot automatically correct silent data loss. The reason is that RAID has no way of knowing which data is correct. For example, if two mirrored copies disagree on the contents of a block, the data is unrecoverable without manual intervention or external knowledge. Furthermore, in normal operation your RAID subsystem will simply read data from whichever drive is idle at the time the read request comes in; it does not ordinarily compare the two mirrors. The data will remain corrupted until the user notices a problem, at which point they have no practical recourse. Essentially the same problem occurs with parity RAID.

    There is no dedicated hardware in your system that provides the end to end data integrity that ZFS does. I honestly suggest you learn more about it before airing your opinions. Here is a start:

    http://blogs.sun.com/bonwick/entry/zfs_end_to_end_ data

  34. Re:Reasons to support? Servers by profplump · · Score: 2, Informative

    If two mirrored copies disagree on the contents of a block, the data is unrecoverable without manual intervention or external knowledge.

    Or, you know, a checksum. Or more than one level of redundancy.

    I agree that RAID-1 cannot, by itself, correctly recover from error-free reads of mis-matched data. But RAID 5 and 6 are both capable of verifying the primary data source against the parity data and transparently correcting errors that occur on less than the critical number of disks. In the common configuration this is only done when a hardware-level error is detected to keep things fast, but it's quite possible to verify every read if so your system is so configured. Mutli-layer RAID also provides this same sort of protection.

  35. Re:Reasons to support? Servers by tbuskey · · Score: 2, Informative

    [ZFS] will be implemented for Linux pretty quickly.

    *sigh*. I wish. ZFS is being implemented on FUSE. This automatically creates limitations in performance and function (no root ZFS). IMO ZFS on FUSE will be a no starter in production.

    I don't think we'll see ZFS in the kernel proper either, given the history of incorporating XFS and ReiserFS 4. Along the same lines, DTRACE will probably never make it in. It's being cloned in the form of Systemtap.

    Meanwhile, FreeBSD has been porting ZFS and DTRACE. MacOSX is (partly) based on FreeBSD and DTRACE has shown up in MacOSX.

    I agree that ZFS is a good reason to convert a file server to Solaris from Linux. FreeBSD may become a good candidate also. I'm a Solaris admin and haven't done much with FreeBSD so I'll lean that way. I'd love to see ZFS in the Linux kernel, but I'm not waiting for it.

    Perhaps the way to go is Solaris x86 with ZFS file server then a BrandZ zone running Linux to provide other functions?

  36. Re:Reasons to support? Servers by Sparohok · · Score: 2, Insightful

    But RAID 5 and 6 are both capable of verifying the primary data source against the parity data and transparently correcting errors that occur on less than the critical number of disks.

    With RAID-5, as with RAID-1, the critical number of disks is one. RAID-5 cannot transparently correct errors that occur on even a single stripe, unless you know a priori which stripe is affected.

    With RAID-6 you can automatically correct errors that occur on a single stripe, but it still does not automatically detect such errors on read the way ZFS and RAID-Z do.

    Or, you know, a checksum.

    That's a great idea. Too bad those ZFS guys didn't think of it. Oh, wait. :)

  37. There's a LOT more to ZFS than snapshots... by toby · · Score: 4, Informative

    Over past months, I've read a lot of people commenting on ZFS who have no idea what it is. What it is, is the next generation of filesystems, not a "tweak" of current fs technology. It just happens to "look like" an ordinary POSIX fs, from a distance (if you ignore the administration/pool stuff...) But inside, it's something new under the Sun, folks.

    RAID experts don't grok it, because it does things RAID can't do (end-to-end).

    Devotees of ext2fs, reiserfs (yay!), NTFS (LOL!), or HFS+ don't grok it, because none of those filesystems do what ZFS does.

    Read about it before you write it off as old wine in a new bottle. To ask the question, "Does OS X need a new filesystem?" is a perfect example of missing the point. Once you've looked at what ZFS really brings to the table, you'll see why it's an inevitable future, sooner or later, and you'll stop looking foolish.

    Some links I posted this week:

    - http://www.osnews.com/story.php/16739/Screenshot-Z FS-in-Leopard - http://mac4ever.com/news/27485/zettabyte_sur_leopa rd/ (older rumour http://www.osnews.com/story.php?news_id=14473)

    For OS X people wondering why the fuss about ZFS - summaries include: - http://www.sun.com/2004-0914/feature/ - http://www.sun.com/bigadmin/features/articles/zfs_ part1.scalable.html

    "Why ZFS for home": - http://uadmin.blogspot.com/2006/05/why-zfs-for-hom e.html

    "Here are ten reasons why you'll want to reformat all of your systems and use ZFS.": http://www.tech-recipes.com/rx/1446/zfs_ten_reason s_to_reformat_your_...

    And some more technical explanations from Chief Engineer: - http://blogs.sun.com/bonwick/entry/zfs_end_to_end_ data - http://blogs.sun.com/bonwick/entry/smokin_mirrors

    --
    you had me at #!
  38. Re:Reasons to support? Servers by Sparohok · · Score: 2, Insightful

    Have you read the link I posted? It is getting old to keep repeating Jeff Bonwick's arguments when you can just read what I already pointed you to.

    The underlying hardware will not necessarily notice errors. Hard drives are only designed to error protect the magnetic domains on the disk. There are all sorts of other places in the increasingly long datapath to disk where data can be lost, and, in fact, routinely does get lost.

    The choice to verify every read is purely an implementation decision

    RAID-6 does not verify every read because it is a stupid way to achieve data integrity. It wastes two thirds of your aggregate IO read bandwidth when you can just use checksums virtually for free. CPU cycles for checksumming is dirt cheap whereas IO bandwidth is extremely expensive.

    I was just arguing the novelity you seem to think ZFS has -- using checksums to verify data integrity is not exactly cutting-edge computer science.

    Yet strangely there aren't any other widely available storage solutions that provide transparent data integrity from the filesystem down.

    I just don't think this particular feature is unique or superior to other available solutions for the same problem.

    Then name another one. I think we've already shown that vanilla RAID does not qualify.

  39. Re:Reasons to support? Servers by larry+bagina · · Score: 2, Funny

    ....raid-{1,5,6,10}.... + reiserfs == survive crash at anytime including a drive physically dying.

    It won't survive a marriage to Hans Reiser!

    --
    Do you even lift?

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

  40. Good Reasons To Support ZFS on Mac by modapi · · Score: 2, Insightful

    Don't any of you guys use Macs?

    Here are five good reasons for Apple to go to ZFS:
    -No more Disk Warrior. The entire data store is self-validating. No bit rot.
    -No RAID controllers needed: ZFS gives you fast RAID for free. Just add drives. Why would anyone care? See #5.
    -No more volumes and, therefore, no more volume management. ZFS eliminates the whole volume concept. Add a disk to your system and it joins your storage pool. More capacity. Not more management. What home user would want that?
    -Continuous Data Protection out of the box. Time Machine could give you a view of your data every time you update a file.
    -ITV, or whatever it is going to be called. Multi-GB files that each cost $10-20, that can't be backed up - thanks DRM! - and therefore need a cheap and highly reliable RAID. ITV, two firewire drives, ZFS and you are in business.
    -Not to mention the existential pleasure of having great technology that Vista doesn't have. In fact, since consumer technology is driving the enterprise, expect ZFS on Mac to raise the bar for every OS and file system.

    I suspect that Time Machine is simply the first of several beautifully designed storage utilities that we'll see on Leopard. How about automatic synchronization when you plug in an external drive? Snapshots automatically exported to .Mac? ZFS enables all kinds of coolness and I, for one, can't wait to get it on my laptop.

    Read more at ZFS On Leopard: How Cool Is That? Means, Motive & Opportunity: Apple Kills the Media Center PC and the latest ZFS On Mac: Now All-But-Official.

    And you heard about the native iSCSI support in Leopard, right?