Hmmm. ZFS, while indeed very interesting, seems to be accompanied by a significant amount of hype. Let's cut through some of it:

ZFS is not particularly fast (nor particularly slow). It does offer above-average small-to-medium-sized update speed (a characteristic of copy-on-write/batch-write-back implementations), but at the cost of streaming-read performance for material thus written (because the small updates are distributed around the storage rather than organized in physical sequence as is the case in extent-based, update-in-place systems with policies that minimize fragmentation). And it has a 'RAID-Z' implementation that can suffer dramatically by comparison to conventional RAID-5 for workloads characterized by lots of parallel small-to-medium-sized accesses (where RAID-Z performs more like RAID-3).

On the other hand, while more conventional file systems may be somewhat faster for many workloads, ZFS does leverage its copy-on-write approach to provide two atypical features:

1. Its updates are intrinsically 'atomic' - even if the system crashes at an arbitrary moment, they either complete, or seem never to have occurred at all. Conventional file systems don't normally guarantee this by default (some files just don't need it, and others require some form of recovery procedure after a crash anyway which can handle any inconsistencies), and those that offer it as an option must write updated material twice: first to a journal that will protect the update, then to the final location - though the journal can be in NVRAM to make the additional overhead negligible, or NVRAM write-back cache in the storage hardware may effectively substitute for the journal, and when material is being written for the first time rather than updated only the structural pointers to it rather than the data itself need be thus protected to guarantee atomicity.

2. ZFS can detect errors that conventional file systems cannot, by virtue of special checksums that it embeds in its metadata. While the frequency of these errors is too low to be important to the average desktop user, in environments with unusually high reliability requirements it provides an edge.

It's worth noting that the 'WAFL' file system in NetApp's line of products provides similar features to those two described above, leading to some discussion about just how much of ZFS actually *is* "Sun's invention".

ZFS's extremely flexible use of a variety of storage devices may be more unprecedented, and for environments that find conventional RAID management challenging (especially when storage must grow) this may be ZFS's most important feature (though it is a feature that some virtualized arrays can come close to equaling when paired with more conventional file systems). Unfortunately, it doesn't help when storage needs grow to exceed the capacity of a single server, but at least makes growth fairly painless up to that point. And the ability to use space flexibly across multiple file systems within a common space pool (similar to the ability to use underlying space flexibly across multiple LUNs in a virtualized array) is also a manageability benefit.

So while ZFS really isn't all that 'close to perfect', nor as entirely novel as Sun might have one believe, on the whole it does constitute a measurable stride forward in storage and while not an ideal fit for everyone should be an excellent fit for some.

Enjoyed the article and comments on ZFS.
However, little mention was made about file naming conventions and compatibility with and between Unix, DOS, Apple and Windows.

Are file names in a pool automatically restricted to the capabilities - or lack thereof - specific to each of these file systems, or does it provide a flexible universal interface?

To wit, Microsoft has all but given up on short file name compatibility with their 'LFN'.

In our home grown fast file management system,
(O'SESAME ffm) we restrict and manage the first four levels within our CRM system in order to provide and maintain an open but controlled 'folder structure' compatible with the above fab' four. The user is still free to name the final file whatever they wish, but we suggest users name their documents using our compatibility reference.

Thanks again for the update.
DKWagner

wow, Paul Venezia's screencast of ZFS, i think that's the worst ZFS screencast ever seen.... i think he spent 10 minutes with ZFS before he started that... embarrassing...

If ZFS is a Sun's invention, then why does it resemble Polycenter Advanced File System so pretty close?
It looks like more an incomplete evolution of ADVFS.
Which one appeared first, after all?

ZFS's unlimited flexibility? Ahem, you can't even remove a device from a pool yet.

From the ZFS FAQ (http://opensolaris.org/os/community/zfs/faq/#deviceremoval):

3. Can devices be removed from a ZFS pool?

Removal of a top-level vdev, such as an entire RAID-Z group or a disk in an unmirrored configuration, is not currently supported. This feature is planned for a future release.

I think srevel should have included the last part of the FAQ article as well:

Can devices be removed from a ZFS pool?

Removal of a top-level vdev, such as an entire RAID-Z group or a disk in an unmirrored configuration, is not currently supported. This feature is planned for a future release.

You can remove a device from a mirrored ZFS configuration by using the zpool detach command.

You can replace a device with a device of equivalent size in both a mirrored or RAID-Z configuration by using the zpool replace command.

So, in essence you CAN remove or replace a device, you just cannot do it unless the data is mirrored somewhere else.

How does this differ from LVM on top of a striped RAID? If I remove a disk from the stripe, the entire volume goes off into the weeds immediately.