Aside – The scourge of filesystems

This morning I had to replace half of a mirror in my Linux server, which being a home server, meant needing to reboot. (Of course I’d love a server with hot-swappable drives, but I suspect both my partner and I might find the noise of such a server somewhat overwhelming for combination computer-room/office.)

So I shutdown the virtual machines running on the HP ML110 G4 (running VMware Server), shutdown the server itself, swapped the drives and rebooted. I promised my partner that internet access would only be down for about 15 minutes, so of course Murphy decided to play a visit.

“Warning, /dev/sdc1 has not been checked in 191 days. Check forced.”

And wouldn’t you know it, /dev/sdc1 is 917GB, so the check took quite a lot longer than 15 minutes. It’s running on ext3, so checking is required less frequently, but I’m still paranoid enough that for the data housed on that particular filesystem, I’d rather not turn checking off altogether. (That filesystem isn’t mirrored, due to transient data on it.)

Having only just read about btrfs, an upcoming filesystem for Linux, the lengthy delay-on-boot caused by a “large” filesystem check was acutely hammered home. Amongst other things, btrfs promises online checks of the filesystem, as well as fast offline checks of the filesystem – something every storage administrator and system administrator wants. We are at the point where filesystem capacities are routinely too large for conventional exhaustive checks. Many more modern filesystems have already achieved this (e.g., ZFS, VxFS, etc.), but it’s a relief to know that such advances are coming, and coming with corporate sponsorship, to Linux.

For an excellent overview of btrfs, check out this short history published on Linux Weekly News.