Fedora and LVM [LWN.net]

Fedora and LVM

Posted Oct 31, 2012 18:46 UTC (Wed) by marcH (subscriber, #57642) [Link] (10 responses)

Resizing and encryption made easier, aggregation made possible. If find it especially used on dual-boot systems where partition tables tend to be trickier anyway.

Fedora and LVM

Posted Oct 31, 2012 20:02 UTC (Wed) by nteon (subscriber, #53899) [Link] (9 responses)

encryption is provided by dm-crypt. I've used it without LVM successfully for a while. Is there a specific way LVM makes it easier?

Fedora and LVM

Posted Oct 31, 2012 22:37 UTC (Wed) by marcH (subscriber, #57642) [Link] (8 responses)

LVM allows several logical (and resizable) partitions, all encrypted at once with a single password in a single, big physical partition spanning almost the entire drive and going totally unnoticed at run time.

Can this be done without LVM? Dunno, maybe. In any case LVM looks like the standard way to do it: well documented, well supported, just works.

Fedora and LVM

Posted Nov 1, 2012 1:38 UTC (Thu) by mstefani (guest, #31644) [Link] (7 responses)

I have full disk encryption on my laptop with dm-crypt and *no* LVM but separate partitions. Works out of the box aka just the one password prompt at boot. And it works since at least F14 after 2-3 bugs in dracut were fixed after I reported them.

Fedora and LVM

Posted Nov 1, 2012 7:56 UTC (Thu) by marcH (subscriber, #57642) [Link] (4 responses)

Care to share more details? Is it really just one password or three times the same password?

Fedora and LVM

Posted Nov 1, 2012 21:34 UTC (Thu) by mstefani (guest, #31644) [Link] (3 responses)

I type the password only once at boot time and all partition (including swap) are decrypted. The UI is exact the same, if you use LVM or not; even in Anaconda.

Fedora and LVM

Posted Nov 1, 2012 23:55 UTC (Thu) by marcH (subscriber, #57642) [Link] (2 responses)

Sorry I wasn't clear. Let me rephrase: do you just have something like three partitions individually encrypted but all in the same way with the same password?

I'm not actually asking about the user interface or about how many times you type this or that but about the internal design. Once I understand the design I (we) will be able to draw my (our) own conclusions :->

Fedora and LVM

Posted Nov 2, 2012 1:15 UTC (Fri) by lacos (guest, #70616) [Link]

I think I can answer, because I have tested both "stackings" (not on Fedora but on RHEL-6).

/dev/sda1 is plaintext boot.

In experiment (a), /dev/sdb2 was handed to dm-crypt (--> /dev/mapper/luks-UUID), which was then formatted as the single PV in a VG, having three LVs (/, /home, and swap). In this case a single password is used.

In experiment (b), /dev/sdb2 was formatted as a single PV in a VG. Three LVs were created, individually encrypted with dm-crypt (using the same password), and then the three separate luks-UUID devices were formatted as /, /home, and swap. The boot process still only asks for "the" password once.

(Unfortunately, the real goal of this experimentation was not reached. The goal was to see if separately encrypting block devices (ie. in exp. (b)) would keep kcryptd from merging "request streams" targeting those separate devices, before they reach the IO scheduler. Alas, it's insufficient; as far as I understand, kcryptd instances (kernel threads?) are spawned per-CPU, not per-device, and whatever requests a given kcryptd instance issues looks same-origin to the IO scheduler, ie. serialized.

Even in experiment (b), an fsync() that follows a big, scattered write on "/" blocks a read request targeting "/home". I've seen stalls as long as 13 seconds on my laptop.

But it's my understanding that this is being worked on.)

Fedora and LVM

Posted Nov 5, 2012 10:26 UTC (Mon) by mstefani (guest, #31644) [Link]

There are four good old standard partitions, all encrypted and I have only one password. As it just worked, without being a nuisance, I happily ignored the implementation details.

Fedora and LVM

Posted Nov 1, 2012 21:01 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

I have the same use case for LVM: I want to encrypt both / and swap, but only enter my passphrase once at boot time. If that works without LVM, I'd happily stop using LVM.

Several encrypted partitions with one password and derived keys

Posted Nov 7, 2012 13:24 UTC (Wed) by emmi3 (subscriber, #62443) [Link]

On my Arch Linux and Ubuntu systems this works with "derived keys" see here: http://crunchbang.org/forums/viewtopic.php?id=4299 for a well written howto. It's a bit dated (now there is 'cryptsetup luksHeaderBackup') but still works.
But I remember reading that systemd did not support the "keyscript" option in /etc/crypttab, which is needed in this setup. Hope this is fixed by the time I upgrade to systemd on my Arch system.

Fedora and LVM

Posted Oct 31, 2012 19:09 UTC (Wed) by lolando (guest, #7139) [Link] (11 responses)

Resizing, as already mentioned, but also: moving data across disks when new disks appear (faster, bigger or simply new and without I/O errors); giving VMs a block device to use as storage rather than a file; snapshots for backups; or, quite simply, just wanting to have various bits of the filesystems on more different "partitions" than can be attained with physical ones.

Fedora and LVM

Posted Oct 31, 2012 22:28 UTC (Wed) by kris.shannon (subscriber, #45828) [Link]

I hate having to deal with systems that aren't using LVM. Growing partitions and moving data between physical disks all while the system is running have saved me so many times...

Fedora and LVM

Posted Oct 31, 2012 23:50 UTC (Wed) by dashesy (guest, #74652) [Link]

Thanks, that is exactly what I wanted to know. Specifically "giving VMs a block device to use as storage rather than a file" is something I find it useful too. I would have tried it if the new cool toy (Btrfs) was on the way.

Fedora and LVM

Posted Nov 1, 2012 12:12 UTC (Thu) by Cato (guest, #7643) [Link] (8 responses)

LVM is good when you require a server to be always up, but it's not really helpful on a desktop - Gparted etc are much easier for resizing or moving partitions (just copy and paste a partition to a new drive) and harder to get wrong for desktops.

Fedora and LVM

Posted Nov 1, 2012 12:42 UTC (Thu) by ricwheeler (subscriber, #4980) [Link] (7 responses)

If you need to change the allocation of space, you will always need something like LVM.

A specific example would be you have say "/" on /dev/sdb and "/home" on /dev/sdc. You discover that you have plenty of unused space in sdb and are running out of room in /home (due to say, storing too mail flame war threads on LVM use).

Obvious solution is to cut down the size of sdb and give that space to /home.

With LVM, the virtual block space can be composed of non-contiguous chunks of physical storage. Without LVM, you can only shrink a partition or grow it into unused space. There is no way to get ext4 or xfs to use that freed up space.

Traditional file system work only on a single device and that block space must be contiguous.

With btrfs, you could shrink sdb, make a new partition in the chunk you freed up and then feed that to btrfs, but that is not the default Fedora file system at the moment.

Fedora and LVM

Posted Nov 1, 2012 12:53 UTC (Thu) by Cato (guest, #7643) [Link] (6 responses)

The use case you mention is exactly what Gparted does - just reboot into Gparted Live CD, edit the partition boundaries (drag and drop one to be larger, other to be smaller), then hit commit and wait for everything to be done.

Gparted is excellent at this - easy to use and very safe in my experience. LVM is much harder unless you already have LVM skills, and even then it's easy to get something slightly wrong.

Fedora and LVM

Posted Nov 1, 2012 14:05 UTC (Thu) by TRS-80 (guest, #1804) [Link]

Gparted somehow has the ability to make filesystems span multiple disks, which is what was implied in the grandparent post? (Expanding /home over /dev/sdb and /dev/sdc)

Fedora and LVM

Posted Nov 1, 2012 15:17 UTC (Thu) by ricwheeler (subscriber, #4980) [Link] (4 responses)

You either misunderstand the example or just need to try it.

Gparted cannot add space from before the beginning of a file system to its end.

You could do a block by block (disk level/offline) copy, but that would be very slow and quite risky.

Fedora and LVM

Posted Nov 1, 2012 15:47 UTC (Thu) by Cato (guest, #7643) [Link] (3 responses)

I missed the part where you implied the free space was not at the end. Clearly some defragging would be needed before using Gparted (an rsnapshot backup and restore into a newly created FS would work fine).

So in this case, LVM might be less work.

Generally I find that partitions tend to fill up and you need to expand them by moving other partitions around that are not as full, and shrinking some of the less full ones - I've not yet had a case where fragmentation prevented this shrinking, so in the no-defrag-needed scenario, Gparted is still much less work than LVM, and a lot easier of course.

Fedora and LVM

Posted Nov 1, 2012 17:48 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

You see, with LVM that 'moving other partitions around that are not as full' case -- always rather hair-raising -- disappears. All you have to do is possibly shrink one fs and expand another one.

I've ended up leaving most space in a VG free until I need it, which means I hardly ever have to shrink fses at all (a good thing because most fses cannot be shrunk without being unmounted). This makes expanding an fs that's out of space, no matter whether it's immediately followed by another fs or not, a matter of five minutes' work with no unmounting, no loss of service, and a near-zero chance of data loss. You just *cannot* do that without some LVM-like indirection layer (in btrfs and ZFS's case, inside the filesystem itself).

Fedora and LVM

Posted Nov 1, 2012 21:29 UTC (Thu) by rleigh (guest, #14622) [Link]

I did this until very recently. I've used LVM on all my systems since LVM came into being, and did online resizing of LVs as and when required. But after recently acquiring an SSD, the system is on Btrfs, with subvolumes used where I would previously have had LVs. No problems so far, though I'm not yet so trusting that /home and /var are still on ext4 on LVM+mdraid. I might move them over once I have gained more trust in it, though after losing an entire RAID1 Btrfs filesystem after a SATA cable glitch earlier in the year, that won't be for a good while.

For me at least the Btrfs improvements are the immediate snapshotting at the FS level, and that the free space is available to all partitions--I don't have to allocate the space up front to the different subvolumes. It would be great if the distribution installers would automatically use subvolumes appropriately when installing onto Btrfs, though I've not checked recently to see how this improved.

Fedora and LVM

Posted Nov 2, 2012 7:17 UTC (Fri) by Cato (guest, #7643) [Link]

I guess it comes down to trusting GParted to get it right for the partition resizing and moving, with it generating all the various commands - I have yet to lose data when using a reasonably recent Gparted and kernel, whereas with LVM there are quite a few commands to get exactly right, and due to write caching/barrier problems on older kernels I have lost data through LVM.

Fedora and LVM

Posted Nov 1, 2012 23:57 UTC (Thu) by Tobu (subscriber, #24111) [Link]

Flexibility. It removes two restrictions that feel idiotic when one encounters them, namely: “oh you still have some space left but you can't give it to that filesystem, it's in the wrong place silly”; “oh you added a disk but you still can't give extra space to that filesystem”. These are punishment for not having supernatural foresight when buying drives and they are enraging. Now Btrfs would also fix these, but stability and performance aren't up to scratch yet.

The other benefit is not nearly as important, but still a good thing. LVM gives the ability to spin up VMs easily without relying on the host filesystem.