Fedora and LVM

Posted Oct 31, 2012 17:03 UTC (Wed) by tialaramex (subscriber, #21167)
In reply to: Fedora and LVM by dwmw2
Parent article: Fedora and LVM

I'm sure it's all possible, it's just not convenient. LVM makes it easier and safer to do this sort of thing, without fumbling around with disk layouts and other stuff you've no reason to care about.

The last time I looked the Fedora UI for LVM sucked pretty badly. But that's not a failing of LVM, it's an opportunity for someone with UI design skills to do a better job. This stuff can be made non-scary, even the Windows Server UI is less scary than what Fedora has now.

It also lets me put off decisions. I have 500GB free, is that space for more video recordings or for experimental software? Never mind, I'll leave it free and assign it when it's needed. Tricky with raw partitions, easy by leaving the blocks assigned to a volume group but not a specific logical volume.

Fedora and LVM

Posted Oct 31, 2012 21:51 UTC (Wed) by epa (subscriber, #39769) [Link] (27 responses)

I can't really agree that 'LVM makes it easier and safer' to do disk-juggling operations. If your system is up and running happily from its system disk, and you have a couple of RAID arrays to manage, then yes. But for single-disk systems it seems to get in the way. For example, suppose you want to upgrade your hard disk. With Slackware it is a simple task to plug in the second disk, boot the machine, partition the second disk and copy everything across, and install the boot loader on the second disk. You're now ready to go. With Fedora and LVM, on the other hand, making it work requires a complex series of LVM commands; fdisk looks positively intuitive by comparison. In the end I gave up trying to move my system to a different hard disk and just reinstalled from scratch. Yay LVM!

To me, LVM is like git. It's hugely powerful; but as a beginner, or someone who doesn't use it often, you really long for a simple interface that will print out "WTF is going on" and guide you through the possible steps.

Fedora and LVM

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

> To me, LVM is like git.

While LVM obviously add some complexity, the comparison with git is really not fair. If you understand git then you can certainly understand LVM with an extremely small effort.

There are only two/three LVM concepts you need to know:

1. Physical partitions: your real, good old disk partitions
2. Volume Group: just an implementation detail you can almost ignore. Have a single VG, assign everything to it and forget about it.
3. Logical partitions: /usr, /home, swap, etc.

Apologies for just making you fully understand LVM against your will.

Fedora and LVM

Posted Nov 1, 2012 4:53 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

Talk about oversimplification! He's going to have to read a lot more documentation to get even the simplest operation done in LVM.

Really, if if the desire is just to to move or resize partitions, it's probably best to use gparted and skip LVM entirely. Not many people actually need the additional features that LVM offers.

Fedora and LVM

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

> He's going to have to read a lot more documentation to get even the simplest operation done in LVM.

I must be a genius then.

The only thing I do besides remembering the above is type the following:

lv[tab] --help
pv[tab] --help
+ say 10 minutes of googling.

That's 15 minutes extra but it's only 15 minutes and it does not happen often.

> Really, if if the desire is just to to move or resize partitions, it's probably best to use gparted and skip LVM entirely.

The key LVM feature for me is: no reboot interruption(s) distracting me at the worst possible moment. If that's not considered important then yes LVM should be skipped.

Fedora and LVM

Posted Nov 1, 2012 8:53 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Yes, if your machine is up and running then you have recourse to "ten minutes of googling". If it won't boot because the initrd doesn't recognize the LVM setup and just falls over in a heap (rather than doing something helpful like, I don't know, displaying a list of volume groups and volumes and letting you choose which to mount as /) then everything becomes a lot more uncomfortable.

Fedora and LVM

Posted Nov 1, 2012 9:29 UTC (Thu) by paulj (subscriber, #341) [Link]

That's not really LVMs fault, but the fault of the init root your distro supplied. That early-boot stuff gets rewritten en-masse regularly and then shipped to you when it still has lots of undiscovered bugs probably means you're the running the regression-guinea-pig version of your favoured vendors' distro.

Fedora and LVM

Posted Nov 1, 2012 15:54 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

Are you really suggesting that with only your previous post, 10 minutes of googling, and the output lvm --help, that epa (or typical Linux users) will be able to easily reconfigure their lvm setups?

Fedora and LVM

Posted Nov 9, 2012 18:13 UTC (Fri) by nahoo (guest, #55570) [Link]

I think he is right. I did this last week. I did a backup, and half an hour later I had all my partitions + filesistems resized, and it was my first try at lvm.

Of course it depends on how you describer a typical user, but I think the statement is true for a user that knows what a filesystem/partition is and need to resize them.

Fedora and LVM

Posted Nov 1, 2012 9:50 UTC (Thu) by mordae (guest, #54701) [Link] (6 responses)

> For example, suppose you want to upgrade your hard disk. With Slackware it is a simple task to plug in the second disk, boot the machine, partition the second disk and copy everything across, and install the boot loader on the second disk.

Yeah, and with LVM you can do that on-the-fly and safely move LVs while using them. You just move the LVs between PVs (the disks) within the same VG and finally you remove the old drive. You can even do it all incrementally.

Fedora and LVM

Posted Nov 1, 2012 11:04 UTC (Thu) by epa (subscriber, #39769) [Link] (5 responses)

Do you have a link to some instructions about how to do this?

I had hoped to set up the new disk without touching the old disk - so there is always a fallback if something goes wrong. If you move the LV to the new disk, that means your old disk will no longer work. I think that for upgrading your hard disk, you usually just want to clone everything to the new disk - only with a larger partition size than before.

Fedora and LVM

Posted Nov 1, 2012 12:57 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (4 responses)

pvcreate "formats" a partition for use with LVM.

vgextend (mentioned in the man page for pvcreate) adds the partition to the existing volume group.

pvmove moves the logical volume from the old disk to the new disk.

vgremove removes the old partition from the volume group.

Remember to move /boot manually (it should be easy to do it with dd since it can be left read-only).

Fedora and LVM

Posted Nov 1, 2012 14:40 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Thank you.

Fedora and LVM

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

s/vgremove/vgreduce/ ; see above (commenting here so you get an email possibly and don't miss the correction)

Fedora and LVM

Posted Nov 1, 2012 21:13 UTC (Thu) by agk (guest, #23332) [Link]

> pvcreate "formats" a partition for use with LVM.

BTW This step is optional now. Basic pvcreate functionality is included in vgextend (and vgcreate).

Fedora and LVM

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

> vgremove removes the old partition from the volume group.

I think this is not correct (it caught my eye because I also have the most trouble remembering this step).

"vgremove" removes an entire volume group.

Instead "vgreduce" is needed here (evict the PV (ie. the partition) from the VG).

Afterwards "pvremove" may be invoked on the partition to "wipe[] the label on [the] device so that LVM will no longer recognise it as a physical volume".

Fedora and LVM

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

Indeed - LVM also makes it harder to recover data (few tools directly support LVM), easier to lose data (on setups where the write caching is broken, but mostly older kernels) and harder to resize partitions (multiple LVM and FS resize commands, and if shrinking is required then it's easy to wreck the FS). And LVM snapshots are pretty slow.

See http://serverfault.com/questions/279571/lvm-dangers-and-c... for more.

Generally I think LVM should only be a default on server distros aimed at professionals. Once btrfs is more mature and has a complete fsck, it removes some of the need for LVM in any case, and has other advantages such as faster snapshots.

Fedora and LVM

Posted Nov 1, 2012 20:49 UTC (Thu) by agk (guest, #23332) [Link] (9 responses)

> (multiple LVM and FS resize commands, and if shrinking is required then it's easy to wreck the FS).

To resize a logical volume containing a recognised filesystem with a single command, use:
lvresize -r ... (or lvextend/lvreduce; or --resizefs)

This passes the size to the filesystem resizing command (via 'fsadm') and runs the steps in the right sequence.

Fedora and LVM

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

I'm aware of the --resizefs feature, but it has been buggy over the years and was apparently only fixed some time in 2011 - see comments 5 and 6 on https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/174032

Most resizing HOWTOs for LVM don't use this command, probably because it was added in the last few years, but that may be no bad thing.

Shrinking an LVM logical volume and FS can be dangerous if you don't get the sizes exactly right, and I'm not 100% confident that the --resizefs feature is bug free. (See http://www.debuntu.org/how-to-install-ubuntu-over-lvm-fil... for a long discussion of issues, and the resizing part of http://serverfault.com/questions/279571/lvm-dangers-and-c...

Generally I have more confidence that Gparted (or parted) will not mess things up.

Fedora and LVM

Posted Nov 2, 2012 14:27 UTC (Fri) by agk (guest, #23332) [Link] (7 responses)

> Shrinking an LVM logical volume and FS can be dangerous if you don't get the sizes exactly right

Which is why --resizefs exists: so that appropriate sizes are used and the steps are performed in the right order. The feature is fully supported.

> and I'm not 100% confident that the --resizefs feature is bug free.

"Bug free" will never be promised, of course:) The bugs you referenced look to be from before the code was included in lvm2 and were of the "feature gives an error and stops instead of resizing" variety.

Fedora and LVM

Posted Nov 2, 2012 17:09 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

And if you insist on using the LVM and FS resizing commands separetely, well at least resize2fs doesn't /need/ any size argument. So just extend the LV, then run resize2fs on its own (no size arg) - it'll figure it out, completely safe.

Fedora and LVM

Posted Nov 2, 2012 17:20 UTC (Fri) by nybble41 (subscriber, #55106) [Link] (3 responses)

That's true only when _growing_ the logical volume; the danger is in _shrinking_ it. To reduce the size of a LV you must first shrink the filesystem, and for that you need the final size of the LV. If you fail to reduce the filesystem to a size less than or equal to the final size of the LV before resizing the LV, the result will be data corruption. Thus the --resize option, which takes care of these details for you.

Fedora and LVM

Posted Nov 5, 2012 12:08 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

For that case I first shrink the fs as much as possible, to size X say. Then I shrink the LV to desired size Y, where Y is unambiguously > X. Then I resizefs without args to increase the fs back to the full size of the LV.

That I do it that way is probably cause I pretty much never shrink fses, and the last time I had to do this was way back, when LVM was still newish and e2fsadm and/or the --resize option didn't exist, or didn't handle this.

Generally LVM lets me manage fses in such a way that I only allocate to them what is reasonable for the foreseeable future. I keep the extra space free in the VG. As/when fses need more space, I just extend them. That this is so painless to do with LVM and resize2fs - online and without interruption - makes it the best way to manage storage, I find.

So so so so much better than the olden days, when you had to rejiggle partitions, reboot several times, and potentially use your swap device as a temporary root, in order to shift space to where you needed it. That was hair-raising, and I never want to go back to that! There isn't much to LVM, it didn't take much to learn, and it's removed a lot of stress.

One lesson though: snapshots need attentive monitoring. Never let a snapshot get anywhere near full, otherwise you risk it getting full and your box will wedge! Also, the early implementations of pvmove were very risky. Apparently those problems have been ironed out and it's now a lot more reliable, but I'm conservative and tend to avoid it. Luckily, that's easy - just move PVs the old fashioned way, copy them like you had to do with FSes before LVM. ;)

Overall though, LVM is a massive win over what went before.

Fedora and LVM

Posted Nov 5, 2012 12:23 UTC (Mon) by Cato (guest, #7643) [Link] (1 responses)

Your 'over-shrink then grow' method is a good one for ensuring the FS doesn't get corrupted when shrinking an LV. However the --resizefs option should be safe and quicker according to agk's comments elsewhere.

Re the "olden days" scenario: now that 2 to 3 TB external drives are very cheap, and USB3 or eSATA are very fast, you can simply backup all the partitions involved (a good idea anyway) to the drive, then repartition destructively and restore. (If you are using rsnapshot you only do an incremental backup since the overnight one, which will not take so long.)

This backup/restore model may be faster than doing the Gparted model of moving FSs to new location, as it uses 2 spindles not one. It also has the benefit of defragging your FSs - I know Linux FSs don't need defragging in theory, but in practice it will help somewhat particularly if FS has been in use for some years. (LVM's model will tend to increase fragmentation somewhat as you never do this sort of FS re-creation.)

I don't see why more than one reboot is needed with Gparted.

Fedora and LVM

Posted Nov 5, 2012 12:32 UTC (Mon) by paulj (subscriber, #341) [Link]

Yes, I might try the --resizefs option next time. I just didn't know about it. It really has been a long time since I last had to shrink an fs.

That single reboot with gparted is still 1 more reboot than I need with LVM. Further, on an ongoing basis, it means you will need a lot more reboots than I will.

Fedora and LVM

Posted Nov 2, 2012 18:02 UTC (Fri) by Cato (guest, #7643) [Link] (1 responses)

Since it seems that "lvextend --resizefs" generally works for common FSs, it's certainly worth a try, but the lack of documentation and HOWTOs mentioning this option doesn't fill me with confidence.

While you are here: I think that the LV size should be larger than the FS size by 2 x the LVM physical extent (PE) size. Is that correct?

Fedora and LVM

Posted Nov 3, 2012 1:28 UTC (Sat) by agk (guest, #23332) [Link]

> the lack of documentation and HOWTOs mentioning this option doesn't fill me with confidence.

The LVM HOWTO at tldp hasn't been updated for several years.

> I think that the LV size should be larger than the FS size by 2 x the LVM physical extent (PE) size. Is that correct?

No. Where did that idea come from? LVM doesn't reserve any space *inside* the LVs it creates! The filesystem can use the entire LV if it wants to.

Fedora and LVM

Posted Nov 1, 2012 22:05 UTC (Thu) by agk (guest, #23332) [Link]

> And LVM snapshots are pretty slow.

That can be qualified: They are optimised to act as short-term backups that will be accessed perhaps just once (if at all) and then deleted.

But because of the lack of alternatives they often get used in other situations where they are indeed 'slow' by design.

An alternative LVM "thin provisioning" snapshot implementation is now available that is optimised for having many long-term snapshots of the same volumes, sharing data between them where they can. Example:

# Set aside 10GB for a pool of thin logical volumes (thin_pool1) in vg1
# and create a thin volume called thin_vol1 that purports to be 2GB in size
lvcreate -T -L10G vg1/thin_pool1 -V2G --name thin_vol1
# Put some data on vg1/thin_vol1
...
# Create a thin snapshot of vg1/thin_vol1
lvcreate -s vg1/thin_vol1 --name thin_snapshot1

Commands that allow the creation of thin snapshots of existing (non-thin) logical volumes are under development.

Fedora and LVM

Posted Nov 1, 2012 15:16 UTC (Thu) by jwakely (subscriber, #60262) [Link]

> To me, LVM is like git.

Except Git is something I find immensely useful and am grateful for daily and therefore is worth bothering to learn.

As I said here last year (http://lwn.net/Articles/459233/) I still don't feel as though I'm missing out on anything by shunning LVM.

Fedora and LVM

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

Your example of leaving 500GB free space for use by either video recordings or experimental software is easily handled with raw partitions and GParted:

1. Create the video and software FSs, say 200GB each, on partitions
2. Leave 500GB unpartitioned free space
3. Decide to expand (say) the video FS, which is before the software FS
4. Use Gparted to move the software FS up by (say) 100GB, and expand the software FS by the same amount.
5. Wait while Gparted does all operations

I haven't included unmount/mount because in some cases using a live CD for Gparted is easier.

My point is that many common FS resizing operations are easily done by Gparted - it will take longer in the 'commit' stage when it does all the work than with LVM (due to moving the data blocks around), but you can leave your system running.

For the typical laptop/desktop case, Gparted + raw partitions are much easier than LVM commands + LVM. For servers where uptime is important, LVM is much better, but it requires some care to get all the commands right.

Fedora and LVM

Posted Nov 2, 2012 16:13 UTC (Fri) by Tobu (subscriber, #24111) [Link] (2 responses)

A LiveCD isn't just easier, it's necessary to be able to unmount partitions that are normally in use. More importantly, step 4 will take a long time and leave you with a thrashed filesystem if an interruption occurs. This is not user-friendly.

Fedora and LVM

Posted Nov 2, 2012 16:27 UTC (Fri) by Cato (guest, #7643) [Link] (1 responses)

I'm aware of why using a live CD is sometimes necessary, didn't think that was essential to mention on LWN.

LVM on older kernels (< 2.6.33) that don't fully support write barriers is also rather dangerous for everyday operations, not just filesystem moves/resizes, unless you turn off write caching in the hard drive (long story, search for "lvm risks" in google).

So whether you use LVM or Gparted, you need to ensure your machine doesn't crash, that the moving-stuff-around app doesn't crash (pvmove has been known to cause data loss due to lack of RAM, see my comments elsewhere).

LVM is somewhat safer if you have a good UPS and have correctly configured write barriers and write caches, but since I use UPSes for my PCs and have yet to had a PSU failure or machine crash during a Gparted operation, I'm happy that the risk is quite low.

In fact the one time I lost data with GParted was when not using a live CD - the rather old kernel + Gparted versions meant that the partition table wasn't properly updated and I omitted to reboot. So a live CD is definitely the way to go.

Whatever method you use, you really need to do a full backup anyway, which guards against the sorts of data-loss mentioned here. So it comes down to speed, ease of use, reliability, etc.

Fedora and LVM

Posted Nov 2, 2012 21:50 UTC (Fri) by Tobu (subscriber, #24111) [Link]

I'm aware of why using a live CD is sometimes necessary, didn't think that was essential to mention on LWN.

I mean, with LVM I don't need to bother with bootable media. I wanted to highlight this difference (this FESCO spat brought up the petty in me, sigh).

Fedora and LVM

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

Last I saw of it (which was years ago, I don't use partitions anymore), if you changed a partition table on a block device which was in use, you had to reboot before the kernel would pick up the new partition table.

That adds a new step 6, 'reboot'. That's a totally unnecessary reboot with LVM.

Fedora and LVM

Posted Nov 12, 2012 3:34 UTC (Mon) by steffen780 (guest, #68142) [Link]

Just run partprobe, always worked for me. I assume there is a reason why this isn't called automatically, but I don't have the slightest clue of what that may be.