Disk layout for XO-1.5 (LVM reliability)
gnu at toad.com
Mon Aug 3 14:23:24 EDT 2009
LVM has a level of appeal. But it caused me a lot of trouble once.
I'd built a striped ext2 filesystem using it, so I could get enough
disk bandwidth to record raw sampled HDTV radio signals in realtime,
using Mandrake Linux and GNU Radio. When I upgraded that system to
Fedora a few years later, the new LVM wouldn't read the old LVM's
partitions, making that filesystem inaccessible.
Turned out there was a bug in the old Mandrake LVM that put the wrong
metadata onto the second and subsequent stripes of a partition. The
new Fedora LVM checked that bad metadata and barfed. It ended up
impossible to fix without going "under the hood", understanding the
block layout and the metadata, and doing some hand editing of the
disk. It was also impossible to copy the data out while keeping the
old disks "read-only", violating another of my long-standing sysadmin
strategies.(*) Ultimately there wasn't that much under the hood --
LVM is a simple format -- but it didn't provide the bulletproof
reliability that I've come to expect from, say, MSDOS partition
(*): ext3 filesystem recovery also has this dubious property -- even
if you mount such a filesystem read-only, ext3 will scribble on it, if
if finds an unclean journal, rather than just "recovering" into its
own in-memory data structures. And it gets harder every year to find
disk drives (or flash drives) with hardware write-protect switches or
jumpers; you end up having to use 'forensic' interface tools to truly
prevent software from writing to a drive whose contents you cherish.
Every flash drive I stick into a Mac, for example, just so it can read
something off the drive, ends up with a root directory full of trash
files created by the Finder. The OLPC's Finder used to do the same,
and perhaps still does.
More information about the Devel