ocschwar | Entries tagged with linux

You're viewing

ocschwar's journal
Create a Dreamwidth Account Learn More

Reload page in style: light

Having been bitten by LVM2 lately more than I ever care to, I got an idea thanks to a SIPB undergrad who asked the right question at the right time. If instead of merging drives with LVM, you merge filesystems using a variant of UnionFS, you can use the disk space on all the drives, but only lose the data on that drive if it goes *poof*, and not the whole filesystem.

It would be a UnionFS mount over ext3 systems on all the drives. Reads would do the obvious things. Write operations would be a little trickier. Writes on existing files would work on the drive that has them, unless that drive fills up, in which case the whole file gets copied elsewhere and the write proceeds there. File creation operations would get stored in the first member filesystem listed which has space available.

Would not take that much of a mod to UnionFS or AUFS. I'm tempted to make this my first attempt at kernel hacking.

Of all the LVM2 command line utilities, only one lets you specify what you want to do by UUID. So say a motherboard dies on you on a Fedora system and you need the data. Well, if you move the drives to another Fedora machine, you now have two volume groups named VolGroup00. The kernel will use the second one for everything. But, when you look at the situation, you'll find both have been fully activated. So when you do "vgrename $UUID $NewName" to clear this up, it will complain that the logical volumes in $UUID are active. But you can't dl "lvchange -an " on them because their name refers to the other volume group. That's where Knoppix comes in.

Still, all that needs to happen is for lvchange to accept UUIDs as arguments. Or, the Fedora install process can start naming the volume groups something like "/dev/$FQDN-VolGroup00".