Fedora and LVM
Fedora and LVM
Posted Nov 1, 2012 23:55 UTC (Thu) by Tobu (subscriber, #24111)In reply to: Fedora and LVM by dwmw2
Parent article: Fedora and LVM
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.
Posted Nov 1, 2012 23:58 UTC (Thu)
by Tobu (subscriber, #24111)
[Link]
Posted Nov 2, 2012 0:19 UTC (Fri)
by dlang (guest, #313)
[Link] (4 responses)
the need to resize anything other than the last partition on a disk (or have a filesystem span multiple drives)
or
the problames caused by LVM
for many of us, the cases where LVM would be useful are much more rare than the cases where LVM is a problem.
I almost never resize partitions after the system is created (especially on production systems)
I would not WANT to have a single filesystem that spanned multiple drives, that's what's known as RAID 0, and it means that if _either_ drive has problems, I can loose the entire filesystem.
meanwhile, the downsides have caused me problems more than once (including cases with colo systems where a drive has partially failed, the facility has replaced the drive and then 'helpfully' plugged in the old drive, now both have default LVM configs and the system is unusable)
Posted Nov 2, 2012 0:46 UTC (Fri)
by Tobu (subscriber, #24111)
[Link] (3 responses)
That's “often” in the first column, and “huh?” in the second. The functionality is pretty basic and I've found it reliable. Most of my experience is from a desktop (long-lived in the same way as Theseus' ship). That said, I don't mind learning from your colo problem. What made it hard to fix? Was the collision on UUIDs or logical names?
Posted Nov 2, 2012 1:13 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
Posted Nov 2, 2012 7:49 UTC (Fri)
by Cato (guest, #7643)
[Link]
One tip for using LVM is to never use the default VG and LV names, to avoid this sort of thing.
I've lost far more time (and data) due to LVM complexities/issues than I have saved through easy expansion/moving of FSs. It makes upgrades and transferring to new PCs much more complex.
Posted Nov 2, 2012 13:07 UTC (Fri)
by Tobu (subscriber, #24111)
[Link]
I've just tried it (using a VM to create a colliding VG name, then kpartx -a to make the nested partitions show up).
Accessing the partition was very easy, but then I had to edit the root= boot parameter to boot the VM (vgcfgrestore to undo the rename would also work). This could be improved by having root= be uuid-based (which Debian/Ubuntu don't do for LVM, don't know about Fedora), as well as by having the Fedora installer pick a more unique VG name.
Debian and Ubuntu pick the hostname as the VG name, this seems like a good way to prevent these collisions entirely.
That was meant as a reply to dashesy, sorry.
Fedora and LVM
Fedora and LVM
Fedora and LVM
Fedora and LVM
Fedora and LVM
Fedora and LVM
$ sudo pvscan
WARNING: Duplicate VG name V2: Existing 5daecde1-e30c-4ef8-bcf6-e501382f67b7 (created here) takes precedence over 8b814833-1a37-47d4-896d-5a8aa74f458f
PV /dev/mapper/sda2p1 VG V2 lvm2 [1016,00 MiB / 0 free]
PV /dev/sda5 VG V2 lvm2 [1,82 TiB / 13,00 GiB free]
$ sudo vgrename 8b814833-1a37-47d4-896d-5a8aa74f458f V3
Volume group "V2" successfully renamed to "V3"