ZFS Shows Up in New Leopard Build 351
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?"
Zettabyte? (Score:3, Informative)
Re:ZFS would be cool (Score:2, Informative)
Re:Reason to support ZFS... (Score:3, Informative)
http://arstechnica.com/staff/fatbits.ars/2006/8/1
Obligatory (Score:3, Informative)
Re:copy-on-write (Score:3, Informative)
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
Re:Just to get it out of the way... (Score:5, Informative)
Re:ZFS would be cool (Score:2, Informative)
Re:ZFS vs HFS vs NTFS? (Score:5, Informative)
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 [sun.com]
Re:Just to get it out of the way... (Score:4, Informative)
Re:Checksumming != no data corruption (Score:1, Informative)
If you have a mirror (RAID 1), you have two copies of the data. When a process requests a read, it gets a copy of the data and does a checksum. If the checksum fails ZFS is smart enough to know that since there's a mirror there's a second copy of the data. It then goes to the second copy and checksums that. If it passes the data is passed to the process, and the bad data is updated with the good data. If the second copy fails its checksum then ZFS returns an error to the process and you've lost your data (which is no worse then what most file systems do today since they don't have checksumming).
If your data is on a ZFS RAIDZ volume (~ RAID 5), then if the checksum fails you can rebuild the data from the parity information.
Most (all?) file systems available today don't have built-in checksumming, so you when request/get data you actually don't know if it's valid. You simply assume that everything from the read from the disk is okay.
Re:copy-on-write (Score:3, Informative)
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.
Re:ZFS vs HFS vs NTFS? (Score:4, Informative)
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.
Re:Reasons to support? Servers (Score:3, Informative)
http://www.apple.com/xserve/management.html [apple.com]
Or this
http://docs.info.apple.com/article.html?artnum=30
Re:What a moron (Score:5, Informative)
Re:Reason to support ZFS... (Score:3, Informative)
Re:Secure Delete? (Score:1, Informative)
Secure deletes are already a 'future version' feature.
http://www.serverwatch.com/tutorials/article.php/3 612066 [serverwatch.com]
Not only secure delete but more general crypto support is planned
http://opensolaris.org/os/community/os_user_groups /nlosug/nlosug-zfs-lofi.pdf [opensolaris.org] [ a pdf presentation on crypto features] r oups/sgosug/10-zfs.pdf [opensolaris.org] [ more general pdf presentation on ZFS ]
http://www.opensolaris.org/os/community/os_user_g
ZFS is relatively new (in comparison to most of the commonly used file systems). It isn't really "done" yet by any means.
Re:copy-on-write (Score:2, Informative)
Re:copy-on-write (Score:3, Informative)
Re:Reasons to support? Servers (Score:4, Informative)
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
Re:Reasons to support? Servers (Score:3, Informative)
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.
Re:Reasons to support? Servers (Score:3, 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?
Re:...so how does one define "capacity" therein? (Score:4, Informative)
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.
There's a LOT more to ZFS than snapshots... (Score:5, 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: [google.com]
- http://www.osnews.com/story.php/16739/Screenshot-Z FS-in-Leopard [osnews.com]
- http://mac4ever.com/news/27485/zettabyte_sur_leopa rd/ [mac4ever.com]
(older rumour http://www.osnews.com/story.php?news_id=14473 [osnews.com])
For OS X people wondering why the fuss about ZFS - summaries include: - http://www.sun.com/2004-0914/feature/ [sun.com] - http://www.sun.com/bigadmin/features/articles/zfs_ part1.scalable.html [sun.com]
"Why ZFS for home": - http://uadmin.blogspot.com/2006/05/why-zfs-for-hom e.html [blogspot.com]
"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_ [tech-recipes.com]...
And some more technical explanations from Chief Engineer: - http://blogs.sun.com/bonwick/entry/zfs_end_to_end_ data [sun.com]
- http://blogs.sun.com/bonwick/entry/smokin_mirrors [sun.com]