OSNews

My interpretation of the original comments were that they were about the customary layering of subsystems in the kernel, which is not something that users see or care about. In other words, I think that he meant that "ZFS does not map directly onto the storage management architecture in the linux kernel and thus would be a pain to implement in linux" and just said it in a sensationalistic way.



Yes! There is no rule saying that ZFS cannot be used over a traditional volume manager, on a loopback file (over NFS), or that a zvol cannot be formatted with a traditional filesystem like UFS. It is just not common.

It's not just that. It's maintainability. When features get added to the wrong layer, it means code redundancy, wasted developer effort, wasted memory, messy interfaces, and bugs that get fixed in one filesystem, but remain in the others.

It does make a difference just how many filesystems you care about supporting. The Linux philosophy is to have one that is considered standard, but to support many. If Sun is planning for ZFS to be the "be all and end all" filesystem for *Solaris, it is easy to see them coming to a different determination regarding proper layering. Neither determination is wrong. They just have different consequences.

Perhaps btrfs will someday implement all of ZFS's goodness in the Linux Way. I confess to being a bit impatient with the state of Linux filesystems today. But not enough to switch to Solaris. I guess one can't expect to have everything.

This is a good, balanced explanation. I think the question is whether the features provided by ZFS are best implemented in a rethought storage stack. In my opinion, the naming of ZFS is a marketing weakness. I would prefer to see something like "ZSM", expanding to "meaningless letter storage manager". Calling it a FS makes it easy for people to understand, but usually to understand incorrectly.

I see ZFS as a third generation storage manager, following partitioned disks and regular LVMs. Now, if the ZFS feature set can be implemented on a second generation stack, I say, more power to the implementors. But the burden of proof is on them, and so far it has not happened.

I too am impatient with the state of Linux storage management. For better or worse, I just don't think it is a priority for the mainline kernel development crew, or Red Hat, which, like it or not, is all that matters in the commercial space. I think ext3 is a stable, well-tuned filesystem, but I find LVM and MD to be clumsy and fragile. Once ext4 is decently stable, I would love to see work on a Real Volume Manager (tm).

From my brief readings on ZFS, you can add remote block devices into the zpool. You can create zraid volumes from the pool. And you can export volumes in such a way that you can put other FS on top. What's so different?

You have a FS, on top of a volume, on top of a RAID, on top of storage devices.



ZFS is not just a filesystem. It is a storage management system that includes device management, volume management, raid management, pooled storage, and a 128-bit filesystem on top of all that.



Please, no. Something architectural like this should not be GPL'd. It should be licensed in such a way that anyone can take it and built upon it (BSD, MIT, X11, LGPL, whatever).

The GPL is great for applications. But lower-level, libraries, architectural stuff should not be GPL'd. Otherwise you get every Tom, Dick, And Harry Co writing their own (usually) incompatible version of the same.



How many more layers do you need?