ZFS

So, I know there have been numerous blog posts gushing about ZFS.

This is another one of those posts.I’ve got “experimental” versions of the filesystem going on a number of Mac hosts, and now on my FreeBSD NAS device. Aside from having been able to cause the OS X version to kernel panic a number of times by doing a a few out-of-the-ordinary things, it has been an excellent experience so far, and I haven’t lost any data.  One of the reasons that those kernel panics didn’t bother me at all was because there is no fsck, no filesystem checking tool.  The filesystem is designed to repair itself on the fly.  In addition it’s also equipped to efficiently deal with power failures, as journaled filesystem are able to do, without a long fsck, except that ZFS doesn’t use journals.

Despite a number of comments about ZFS “really needing” a 64-bit CPU and gobs of memory, this requirement appears to be quite scalable.  For a home-based NAS device where most of the time only one client is being served, it seems to do fine even on an old VIA C3 800Mhz with 512MB of RAM.  It certainly won’t break any speed records for data transmission, but the data that makes it on there is in a raidz1 and so if 1 drive dies, it’s no big deal.  In addition, if something happens to a disk between times when ZFS is working with it, or if there’s an error that the drive doesn’t deal with appropriately ZFS will realize that the checksums don’t match on the reads it is doing and will repair the damage on the erring drive.  Unless you disable it, every last block of data you write out to disk in ZFS is checksummed.  So, not only can you be relatively sure that your data are safe, but you know if it has become corrupted, and in most cases with redundancy the filesystem can fix it.Did I mention that it also supports transparent data compression?  Enable the option and all data written to the drive after that point is compressed with no need to wait 8 hours to recompress all the data already on disk (though I believe some functions are being considered to allow forced recompression of data).  While I think, perhaps, on my little NAS device this might actually slow things down a bit, in many workloads Sun has indicated that compression actually speeds up data access because for many of the lightweight compression algorithms used the CPU hit is small, and less data needs to be actually pulled from the device when read.

Honestly, aside from some ironing out that needs doing on some of the fresher ports of this filesystem, I see no downsides to it.  It may not work well on a 200 Mhz machine, but something closer to 1Ghz is enough, even a Via C3, which is probably at 800 Mhz comparable to a 500-600Mhz Pentium/PentiumII. Did I mention that creating new filesystems on a pool costs essentially nothing and that you can do snapshots and clones that are quite efficient and only need to store the blocks that have changed rather having a whole duplicate image of a filesystem?

In another week or so I’ll likely post up some comments about tuning usage on the NAS if any tuning is really necessary.