Why I want a solid ZFS implementation on Linux

February 9, 2014

The short version of this is 'ZFS checksums and ZFS scrubs'. Without strong per-block integrity protections, there are two issues that I increasingly worry about for my Linux workstations with mirrored disks: read errors on the remaining live disk when resynchronizing a RAID-1 mirror after it loses one disk and slow data loss due to undetected read errors and corrupted on-disk data. Slow data loss is also a worry for backups on a single backup or especially an archival disk (I'll have more than one archive disk but cross-verification may be very painful).

(ZFS also offers flexible space management for filesystems, but this is less of an issue for me. In practice the filesystems on my workstation just grow slowly over time, which is a scenario that's already handled by LVM. I might do some reorganization if I could shrink filesystems easily but probably not much.)

ZFS's block checksums combined with regular scrubs basically immunize me against these creeping problems. Unless I'm very unlucky I can pretty much count on any progress disk damage getting repaired, and if I'm unlucky at least I'll know about it and maybe I can retrieve things from backups. Of course in theory Btrfs can do all of this too, but btrfs remains not ready for production and unlike ZFS this applies to the fundamental code, not just the bits that connect the core ZFS code to Linux.

(That ZFS is not integrated into the mainline kernel also makes it somewhat risky to use ZFS on distributions like Fedora that stick closely to the current mainline kernels and update frequently. Btrfs is obviously much better off here, so I really wish it was stable and proven in widespread usage.)

I suppose the brute force overkill solution to this dilemma is an OmniOS based fileserver that NFS exports things to my Linux workstation, but there are various drawbacks to that (especially at home).

(Running my entire desktop environment on OmniOS is a complete non-starter.)

(This is sort of the background explanation behind a tweet.)


Comments on this page:

From 46.144.78.131 at 2014-02-11 03:20:01:

me too, but it is not going to happen unless the license allows it. So ...

A zfs tank at home is what I have (a hp microsever n40l, really cheap, 4x3Tb disks and a ssd for larc/zil). I mainly use my laptop, so no homedir on that, but I do synchronize it with the zfs tank. Of course it does a whole more stuff, like downloading stuff, serving files for the xmbc macmini connected to the tv, central cifs backup store for the kids using robocopy ...

Besides, using crashplan (they have software for solaris which just works) I have off-site backups ;-)

It used to be my nfs datastore for my esxi homelab, but that one died recently and will not be replaced because I got most of the functionality using zones.

So yes, it could be overkill to have a zfs server, but if you have it, you can always put it to work and in my case I learn a lot about solaris based systems I did not know before.

Written on 09 February 2014.
« Why I'm not looking at installing OmniOS via Kayak
My dividing line between working remotely and working out of the office »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sun Feb 9 20:58:04 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.