Solaris Filesystem Choices
Linked by John Finigan on Mon 21st Apr 2008 19:00 UTC
Oracle and SUN When it comes to dealing with storage, Solaris 10 provides admins with more choices than any other operating system. Right out of the box, it offers two filesystems, two volume managers, an iscsi target and initiator, and, naturally, an NFS server. Add a couple of Sun packages and you have volume replication, a cluster filesystem, and a hierarchical storage manager. Trust your data to the still-in-development features found in OpenSolaris, and you can have a fibre channel target and an in-kernel CIFS server, among other things. True, some of these features can be found in any enterprise-ready UNIX OS. But Solaris 10 integrates all of them into one well-tested package. Editor's note: This is the first of our published submissions for the 2008 Article Contest.
E-mail Print r 8   · Read More · 87 Comment(s) http://osne.ws/f69
Thread beginning with comment 310901
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Background articles
by Abacus_ on Tue 22nd Apr 2008 18:51 UTC in reply to "RE[3]: Background articles"
Abacus_
Member since:
2006-12-08

"[q]ZFS is not a pure-play log structured FS and requires no cleaner.


That's an interesting statement. Can you tell me where I can more information about the fact that ZFS doesn't require a cleaner ? "

Check this out:
http://blogs.sun.com/nico/entry/comparing_zfs_to_the_41

By saying that it doesn't require a cleaner, what I had in mind is that it isn't background garbage collected and does not treat the disk as a circular log of segments that are either clean or dirty. It is more like a versioned tree of blocks. By cleaner I mean an asynchronous daemon that eventually "gets around to" cleaning segments that are dirty.

However, I am always willing to learn something. Do you think this evaluation is incorrect? [/q]

As known, filesystems like ZFS and the Sprite LFS write data to a huge log. This log contains both data and metadata. I'm not a ZFS expert, but how can ZFS discover unreferenced blocks without rereading the metadata that was written earlier to the log (assuming that not all metadata fits in RAM) ?

Reply Parent Score: 1

RE[5]: Background articles
by Weeman on Tue 22nd Apr 2008 19:55 in reply to "RE[4]: Background articles"
Weeman Member since:
2006-03-20

I'm not a ZFS expert, but how can ZFS discover unreferenced blocks without rereading the metadata that was written earlier to the log (assuming that not all metadata fits in RAM) ?

The metadata and spacemaps are COW as well. All written data isn't live until the uberblock is written, which happens as last thing in a transaction group. If ZFS fails to commit a transaction group, that is the uberblock not getting written, there were practically no blocks allocated since the new updated spacemaps aren't being referenced by the updated metadata tree, which itself is also not referenced by the current uberblock.

So in theory, there can be no unreferenced blocks, unless it happens due to bugs in ZFS. In this case, it has to walk the metadata tree and check it against the spacemaps.

...that is if I got your question right.

Edited 2008-04-22 19:56 UTC

Reply Parent Score: 1