Fedora and LVM

Posted Nov 2, 2012 14:27 UTC (Fri) by agk (guest, #23332)
In reply to: Fedora and LVM by Cato
Parent article: Fedora and LVM

> 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.