LWN: Comments on "Fedora and LVM"

Beginning LVM support in GParted

JanC_ — Thu, 15 Nov 2012 17:37:05 +0000

Thanks to our new GParted developer, Mike Fleetwood, for working on that... :)

Fedora and LVM

steffen780 — Mon, 12 Nov 2012 03:46:38 +0000

Posted this further above, but this has become a rather lengthy comment thread.. just run partprobe. I've used this with mounted in-use FSs many times without any problems.
Disclaimer: I have no idea if doing this is dangerous, but it has never bitten me.

Fedora and LVM

steffen780 — Mon, 12 Nov 2012 03:34:39 +0000

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.

Fedora and LVM

mfedyk — Mon, 12 Nov 2012 03:01:04 +0000

I believe you can have the partition table reread while one or more of the partitions have mounted filesystems on them in the 3.6 kernel now.

That may be a reason for the attempted change in f18. The ability to extend a partition online without needing lvm.

Fedora and LVM

nahoo — Fri, 09 Nov 2012 18:13:45 +0000

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

faramir — Wed, 07 Nov 2012 18:26:29 +0000

That's quite a lot of manual labor for every time you want to do a revertable upgrade. Which if it was easy enough, I think many would want to do for every upgrade.

Setting up LVM (with snapshots for /) might be a bit more difficult during the initial install, but it seems to me it is going to be a lot more convenient in the end.

In either case, you have to have done something up front during the initial install. i.e. Either used LVM or set aside a partition for your second root.

Several encrypted partitions with one password and derived keys

emmi3 — Wed, 07 Nov 2012 13:24:36 +0000

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

emmi3 — Wed, 07 Nov 2012 13:00:35 +0000

But it's not so much different either. I've ben using this "two primary root partition"-setup for quite some time on all my systems at work. Although I usually prefer to reinstall my desktop systems, this is how I would handle the "revertable upgrade" case:

- create an new filesystem with a different label on the unused partition
- copy the old system over
- change the label for the root filesystem in /etc/fstab to the new one (I would also grep through /etc/ for the old label eg. xubuntu1204, debian60, just in case)
- chroot into the new system and install grub to the new root partition and update-grub (or install and reconfigure extlinux... :)
- activate the new and deactivate the old partition
- reboot

If anything goes wrong just reboot into the old root. Using "MBR" this is a simple matter of pressing the shift-key and choosing the right partition at boot time.

Fedora and LVM

admax88 — Tue, 06 Nov 2012 16:52:05 +0000

Most of the original GNU software is still in CVS.

Just because a project doesn't adapt to the new hotness in version control doesn't say anything about the quality of the code.

The choice of VCS is more likely an indicator of the age of the project and/or the age of the developers.

Fedora and LVM

nix — Tue, 06 Nov 2012 16:45:39 +0000

True. There are rare exceptions even here. (I can't think of many, though.)

Fedora and LVM

admax88 — Tue, 06 Nov 2012 16:19:57 +0000

OpenBSD uses CVS, and its pretty actively maintained and very high quality.

Fedora and LVM

nix — Tue, 06 Nov 2012 13:33:19 +0000

The thing is, that's pretty much not true. Sure, dealing with such version control systems is painful, but if I followed those rules, I'd lose the source trees for Emacs, KDE (before the recent move to git), Enlightenment, Calibre... there's no real correlation between quality and choice of VCS, though if someone is still using CVS it is probably a sign that the project is not very actively maintained. Equally, there's no correlation between 'project is forced to use SysVIPC to interoperate with other software' and general quality -- only if the project used SysVIPC when it had another choice can such a conclusion be drawn.

Fedora and LVM

paulj — Mon, 05 Nov 2012 12:32:15 +0000

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

Cato — Mon, 05 Nov 2012 12:23:32 +0000

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

paulj — Mon, 05 Nov 2012 12:08:37 +0000

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

dwmw2 — Mon, 05 Nov 2012 11:04:53 +0000

It's a generalisation. Of course it isn't 100% accurate but it's a good predictor. It's much the same as "code stored in BZR or SVN probably isn't worth the pain of trying to get it out of its antiquated version control system to look at it" — there are exceptions, but they are few.

Fedora and LVM

nmav — Mon, 05 Nov 2012 10:51:56 +0000

> Actually I am concerned about the implementation. The fact that the LVM/dm
> userspace bits heavily rely on stuff such as sysv semaphores and things is
> just awful. If code uses SysV semaphores then this usually is a pretty
> strong sign that something is not right about the code, i.e. either that
> it hasn't been touched in decades, or that it simply is questionnable code.

I like those generalizations. If a thing does A it is crap. While semaphores may be used in bad code, there is nothing to indicate bad code because it uses semaphores. Semaphores are a tool (arguably an old one), but as every tool it can be used in a bad way or _not_.

Fedora and LVM

mstefani — Mon, 05 Nov 2012 10:26:16 +0000

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

marcH — Sun, 04 Nov 2012 11:28:55 +0000

> move any partitions as required until the free space is next to the partition you want to enlarge

The only reason you find this "easier" (I clearly don't) is because GParted has a graphical interface while LVM has not (yet?).

To the best tool is quite often the one you are the most familiar with.

When repartitioning I trust nothing and no one (neither GParted nor myself). So I much prefer spending 10 minutes googling and reading the LVM man pages and eventually do something conceptually simpler and that involves 5 or 10 times fewer operations, i.e, 5 or 10 times less chances for something to break.

Fedora and LVM

Cato — Sun, 04 Nov 2012 07:13:52 +0000

GParted has just added (as of mid Oct) support for read-write of LVM2 PVs - http://gparted-forum.surf4.info/viewtopic.php?id=16575 - of course, the usual caveats to bleeding edge code apply, but if you have good backups it would be worth a try.

Fedora and LVM

dlang — Sat, 03 Nov 2012 20:39:47 +0000

> t's good for servers where high uptime is needed,

being a bit picky here.

servers don't need high uptime, the services they provide need high availability time. This is not the same thing (even though it sounds like it should be)

pushing for high uptime on a single server will get you quite a ways towards high availability time, but then you hit a wall and you need to move to cluters of machines. Once you move to clusters of machines, the need for high uptime on a each individual server drops dramatically.

While the clustering adds complexity, this now allows for management of the indivudal servers to be much simpler as you are no longer racing the clock for each change. This (usually) results in a very dramatic improvement in service availability, and a dramatic _decrease_ in _unplanned_ server downtime. there is more _planned_ server downtime, but it's the unplanned downtime that your customers notice.

There is a small (and shrinking) pool of application types that are really hard to cluster and really do need high uptime, but far fewer than you would think.

Fedora and LVM

Cato — Sat, 03 Nov 2012 18:14:30 +0000

GParted can cover this fine including the Windows volume shrinking:

- shrink Windows volume
- move any partitions as required until the free space is next to the partition you want to enlarge
- drag the boundary of that partition to fill the free space
- hit Commit button
- come back some time later to find it's all done

For a desktop/laptop this can be done overnight, and is so much easier than having to mess with LVM (as I used to do, making copious notes on the right commands so I could remember them next time, since such rearrangements are not a weekly occurrence.)

LVM is great for other use cases but unless you have a very high uptime requirement for your PCs, and are expert in LVM, it's not for laptops/desktops.

Of course if there was a Gparted-like tool for LVM, this might change the picture - why reboot into Gparted if an "LVM edit" GUI tool does the same thing?

Fedora and LVM

Cato — Sat, 03 Nov 2012 18:10:37 +0000

Actually you can just use Copy and Paste on entire partitions in Gparted - very nice feature e.g. if you want to move to a larger disk then expand some partitions.

Fedora and LVM

Cato — Sat, 03 Nov 2012 18:08:35 +0000

Actually I've used LVM a fair bit on various Linux systems, and got burnt by it, including significant data loss (write barriers not being implemented, mostly). Then I was very anti-LVM, now I have a more balanced position, in my view: it's good for servers where high uptime is needed, but overkill for most desktops where raw partitions and Gparted are safer and easier.

I am about to extend use of LVM on one server where I need to add a large disk, and want a single huge LV across several disks. (Something that the raw partition model can't deliver).

However, on a laptop/desktop I would not use it (perhaps for a desktop to span disks, but not within a single disk.)

I would not have spent this much time ranting about LVM if I had not used it quite a lot...

Fedora and LVM

Cato — Sat, 03 Nov 2012 17:54:56 +0000

I've just realised that I seem to have had this problem on a server using LVM a while back - I didn't have time to investigate so I just put a "vgchange -ay" into the /etc/init.d/checkfs script. This is on Ubuntu 8.04 LTS server, so it's a cross-distro issue, and the hard disks are SATA.

Presumably an earlier invocation had failed, with the result that the fsck step failed, causing boot to fail. A shame that LVM, which generally helps uptime in many cases, caused downtime here - presumably btrfs wouldn't have this issue as it doesn't require this extra 'vgchange' type step.

I really look forward to btrfs (or perhaps ZFS in-kernel) being mature enough to use, largely for the parent-block checksumming to catch various errors.

This is on a home server in an inconvenient location, where there is only voltage regulation not UPS, and the utility power is flaky - so reliable unattended reboots are really helpful.

Fedora and LVM

agk — Sat, 03 Nov 2012 01:28:47 +0000

> 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

cmccabe — Fri, 02 Nov 2012 23:37:19 +0000

I didn't realize that LVM could handle this scenario. Thanks for pointing that out.

To be honest, I never like to make changes to the partition table of a disk without rebooting or hotplugging the disk. The kernel sometimes doesn't refresh its view of the partition table (or has this been fixed in newer kernels?). So while online resize of physical (windows) partitions without rebooting may be possible in theory, I'm not sure if I would choose that route for an internal disk.

Fedora and LVM

Tobu — Fri, 02 Nov 2012 21:50:47 +0000

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

nix — Fri, 02 Nov 2012 20:39:30 +0000

One saving grace of LVM is that the metadata backups are not just kept in /etc/lvm. They are *also* kept in a defined place on every PV (IIRC at the start), in ASCII. So if you are so badly shagged that you've lost / and vgscan can't reconstruct your VG, you can get started by sucking the metadata off the PV with dd. (But normally as long as the PVs are there the VG can be reconstructed. A VG doesn't have any existence beyond its PVs, after all: there is no 'VG area' that can get damaged to destroy your VG.)

Fedora and LVM

phiggins — Fri, 02 Nov 2012 19:06:02 +0000

I used to run Fedora as my primary OS on my work laptop. I resized the Windows partition down but didn't remove it, and that left me with little space to actually work in. I put /home on a USB drive and used LVM. It was a huge mistake for exactly the reasons mentioned. It rarely was mounted automatically and caused big problems (I don't remember exactly what they were now) whenever the USB cable accidentally became disconnected.

I honestly can't remember why I used LVM in the first place, but Fedora using it by default probably influenced that decision.

I used to be in the "LVM is worthless confusing overhead for a desktop and even small servers" camp. Now that I have more experience with it after using it for years *because* Fedora made it the default, I have found its features useful a few times per year. However, I am still nervous that one day I will be unable to recover my data because LVM is too complicated and I won't know how to restore a non-booting system.

Fedora and LVM

Cato — Fri, 02 Nov 2012 18:02:12 +0000

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

nix — Fri, 02 Nov 2012 17:38:42 +0000

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

nix — Fri, 02 Nov 2012 17:35:58 +0000

It doesn't even need to be a second file. You can link it into the kernel, and then you don't need to worry about *ever* ending up with a kernel without the initramfs, or vice versa, or version skew between them.

Fedora and LVM

nix — Fri, 02 Nov 2012 17:31:29 +0000

Oh it started as handwaving -- i.e. I didn't do more than simple blktrace benchmarking for a few minutes to look at the relative write rates after the initial mkfs -- but it became clear in the recent ext4 corruption fiasco that the handwaving had a basis in fact :) I corrupted /var repeatedly, and /home once or twice at most.

Fedora and LVM

nybble41 — Fri, 02 Nov 2012 17:20:46 +0000

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

paulj — Fri, 02 Nov 2012 17:09:04 +0000

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

johannbg — Fri, 02 Nov 2012 16:32:22 +0000

Please enlighten me how this greatly reduce the capability of the system or increase the fragility of the boot process ( given that I have not been bit by several bugs we have encounter with the initramfs ) or how I cant use encrypted block devices ( like I'm currently doing ).

I dont need or want lvm I dont use hw or sw raid and if I need additional storage I buy external disks or rather use my spideroak account on the cloud to share across all my devices and where I dont have to worry about the disk failing and I could loose my data or I simply use my own local nas at home.

I'm not saying that users should not be able to setup and use initramfs but for laptop/desktop use cases I dont see the argument why they need it

I certainly dont and I prefer faster and more reliable bootup.

Fedora and LVM

Cato — Fri, 02 Nov 2012 16:27:39 +0000

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

Tobu — Fri, 02 Nov 2012 16:13:23 +0000

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

raven667 — Fri, 02 Nov 2012 15:15:24 +0000

I doubt that's actually true, there are many different requirements for desktop/laptop users that work best with or require initramfs setup at boot time. The only way to not need it is to greatly reduce the capability of the system or increase the fragility of the boot process. If you want encrypted block devices, software RAID, dependency ordering for hardware initialization, etc. then it's best to do that from an initramfs. Maybe you don't want these things but other people do so it has to be supported by default.