Fedora and LVM
| This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible. |
Those following the progress of the Fedora 18 development cycle cannot have failed to notice that the rework of Anaconda, the distribution's installer, is not going as smoothly as one might have liked. Complaints are common, and there is a real risk that installer problems will end up being what users remember about this release. Given that, it may seem surprising that the Fedora developers intend to change one of the fundamental decisions made by the developers of the new installer.
The logical volume manager (LVM) sits above the block layer, providing abstract storage devices that can be resized, encrypted, and more. In the absence of explicit instructions to the contrary, Anaconda has installed systems using LVM for many years. LVM adds some flexibility to an installed system and supports a number of official Fedora features, but it has the potential to confuse users who are not prepared for the addition of a layer of indirection over their disk partitions. It also irritates users who know they don't need LVM and would rather not see another layer of software in the block I/O path. Grumbling about the use of LVM in Fedora is not uncommon.
The new installer changes the default; unless the user asks for LVM explicitly, current F18 testing releases will install directly onto disk partitions and leave LVM out of the picture. How that change came to be is not entirely clear; it does not seem that there was much, if any discussion in the Fedora development community first. That did finally begin, though, on October 25, when Adam Williamson filed a Fedora bug asking that the change be reverted so that Fedora would, once again, install and use LVM by default.
That discussion got off to a bit of a rough start; arguably, Adam's phrasing did not help matters:
In the end, though, the real arguments in favor of changing Anaconda to restore LVM-by-default came to the fore; there are several of them. The first of these is that a number of advertised Fedora features depend on LVM; a user who does without LVM will end up without the ability to use System Storage Manager, resize filesystems, migrate filesystems across disk, and more. Thus, Ric Wheeler said, turning LVM off by default constitutes a regression that needs to be reverted.
There is also the little problem that Fedora's documentation is written with the assumption that LVM is in use. Turning LVM off obsoletes that documentation without fixing it. Quality documentation is hard enough to come by as it is; causing what documentation exists to become inaccurate without (as LVM proponents see it) a proper justification just makes things worse to no good end.
Also relevant is that the current plan is for Fedora to switch to Btrfs during the Fedora 19 development cycle. Given that, making a fundamental change to the Fedora storage stack now makes little sense to many developers. It will just add churn to a system that is going away anyway, leaving one Fedora release with a storage setup that differs from all the others. That has the potential to confuse users and increase the amount of work the Fedora storage developers have to put into supporting the F18 release. Even if the Btrfs transition is delayed to F20 (an outrageously shocking and unpredictable course of events, but one might as well ponder even highly unlikely scenarios), a case could be made that it might be better not to perturb the existing stack unnecessarily in the meantime.
Finally, it has been pointed out that the change to Anaconda returning it to the pre-F18 default is quite small; it is really just changing the default value of a checkbox on an installer screen. All of the code for installing over LVM — code that has been used for many releases — is still there and working as well as ever. So the change should be safe and should not be cause for yet another slip in the Fedora 18 schedule.
Arguments for leaving the default as it is (and, thus, continuing to install without LVM) usually start with the fact that it is quite late in the F18 development cycle; unnecessary changes — even small and seemingly safe changes — should be avoided if possible. That is doubly true for the installer, which has had trouble stabilizing as it is. Rather than revisit established decisions, it is said, it would be better to focus on fixing the known problems and getting a solid release out the door.
Beyond that, some developers question the value of LVM. Fedora developer "drago01" asked:
LVM has been fingered in the past for slowing down the boot process; indeed, it has been called out as one of the chief offenders. Discussion in the bug report suggests that LVM's dependency on udev-settle, which is the real cause of boot-time delays, has been significantly reduced, to the point that many or most installations no longer need it. But, if boot time is a prime concern, the addition of another service to set up in the boot path is unlikely to help the situation.
Finally, opponents argue that LVM is confusing to relatively unsophisticated users who will end up being unable to manage their systems properly. It is an added level of abstraction that makes things harder without bringing any significant new value. It would be better, they argue, to behave like many other distributions and just install directly onto disk partitions by default.
The Fedora Engineering Steering Committee (FESCO) took up this issue and
brought it to a vote on October 30. Full consensus was not to be
found there either, but, in the end, FESCO voted in favor of the change
back to the pre-F18 default.
So, unless something gets derailed somewhere, the Fedora 18 will, like
its predecessors, install and use LVM by default.
(Log in to post comments)
Fedora and LVM
Posted Oct 31, 2012 16:27 UTC (Wed) by amacater (subscriber, #790) [Link]
A netinst (220M download) install offers you the choice of filesystem on a single disk (LVM/not LVM), guided disk partitioning with several common variants or manual partitioning and, of course the chance to set up RAID and LVM in detail for a multi-disk system
Fedora and LVM
Posted Oct 31, 2012 16:35 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Fedora and LVM
Posted Oct 31, 2012 17:03 UTC (Wed) by carenas (subscriber, #46541) [Link]
Fedora and LVM
Posted Oct 31, 2012 18:27 UTC (Wed) by seyman (subscriber, #1172) [Link]
Fedora and LVM
Posted Oct 31, 2012 16:36 UTC (Wed) by dowdle (subscriber, #659) [Link]
Debian's installer (was Fedora and LVM)
Posted Oct 31, 2012 19:07 UTC (Wed) by dskoll (subscriber, #1630) [Link]
Just out of curiosity... what's wrong with Debian's installer? I rather like it.
Fedora and LVM
Posted Oct 31, 2012 19:26 UTC (Wed) by pkern (subscriber, #32883) [Link]
"The GUI one" being just another frontend to the same code. Hence it not providing that much more functionality over the text mode install. Luckily that has the benefits of an identical feature set and less maintenance being required.
Fedora and LVM
Posted Oct 31, 2012 16:42 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]
My biggest problem with LVM is that it's massively more fragile than the basic partitioning setup. And, as noted, with no real benefit in the basic laptop/desktop case.I run a number of machines, and mostly I remember to disable LVM when installing them. I have lost count of the number of times that something's gone wrong with the ever-increasingly-baroque initrd, leaving mount-by-UUID and LVM non-functional, while a simple boot with 'root=/dev/sda2' has been sufficient to get it working again. And of the number of times that I've attempted to perform a similar task on an LVM-inflicted machine, and been screwed.
I have, on the other hand, resized partitions and switched from dual-500GB disks in RAID-1, to dual-1½TB disks in RAID-1, without having to use LVM. So even on the rare occasion that I've actually done disk-juggling stuff, LVM didn't help me.
Fedora and LVM
Posted Oct 31, 2012 17:03 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
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]
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]
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]
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]
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]
Fedora and LVM
Posted Nov 1, 2012 9:29 UTC (Thu) by paulj (subscriber, #341) [Link]
Fedora and LVM
Posted Nov 1, 2012 15:54 UTC (Thu) by bronson (subscriber, #4806) [Link]
Fedora and LVM
Posted Nov 9, 2012 18:13 UTC (Fri) by nahoo (guest, #55570) [Link]
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]
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]
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]
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 2, 2012 0:34 UTC (Fri) by lacos (guest, #70616) [Link]
Fedora and LVM
Posted Nov 1, 2012 21:13 UTC (Thu) by agk (guest, #23332) [Link]
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]
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]
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]
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]
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]
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]
Fedora and LVM
Posted Nov 2, 2012 17:20 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
Fedora and LVM
Posted Nov 5, 2012 12:08 UTC (Mon) by paulj (subscriber, #341) [Link]
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]
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]
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]
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 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]
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]
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]
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]
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]
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]
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]
Fedora and LVM
Posted Oct 31, 2012 17:27 UTC (Wed) by nix (subscriber, #2304) [Link]
LVM has its nasty delicate corners (be scared of snapshots, for instance), but as a 'make it bigger when needed' tool, it still does the job, and is not notably unreliable in my experience.
Fedora and LVM
Posted Oct 31, 2012 17:51 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Fedora and LVM
Posted Oct 31, 2012 18:31 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]
Fedora and LVM
Posted Oct 31, 2012 20:55 UTC (Wed) by rleigh (guest, #14622) [Link]
The schroot tool uses LVM snapshots to create and destroy transient scratch build environments. We use them on the Debian autobuilders. If you kick off 24 parallel builds on a 24 core system, the system will be dead as a doornail in a few tens of seconds. Entirely due to lvcreate/lvremote triggering what looks like some kernel locking bug. Even on systems only running a single build, we still regularly have lvcreate and lvremove failures. There's some fundamental bugs in LVM which really need fixing, and which I'm surprised haven't been addressed given that they are easily reproducible. schroot is admittedly a special case--most people don't churn through as many LVs as we do--rebuilding the whole archive is ~14 hours with 24 parallel builds, and ~18000 transient LVs (though it always died in under 5 mins, less than 100 LVs in). But it should certainly work without killing your system.
We now also support btrfs snapshots, and while the filesystem itself is still not perfect, I've not yet run into a single issue doing heavy parallelised snapshotting.
Fedora and LVM
Posted Oct 31, 2012 21:58 UTC (Wed) by BlueLightning (subscriber, #38978) [Link]
Fedora and LVM
Posted Oct 31, 2012 22:18 UTC (Wed) by rleigh (guest, #14622) [Link]
Fedora and LVM
Posted Nov 1, 2012 21:39 UTC (Thu) by agk (guest, #23332) [Link]
Please would you dig up and post a link to this here?
Fedora and LVM
Posted Nov 1, 2012 23:23 UTC (Thu) by rleigh (guest, #14622) [Link]
Fedora and LVM
Posted Nov 2, 2012 0:11 UTC (Fri) by agk (guest, #23332) [Link]
Fedora and LVM
Posted Nov 2, 2012 0:28 UTC (Fri) by rleigh (guest, #14622) [Link]
Fedora and LVM
Posted Nov 1, 2012 12:06 UTC (Thu) by Cato (guest, #7643) [Link]
The non-snapshot LVM/DM code is not too bad, though there are some tools issues - e.g. pvmove can corrupt data if it runs out of memory - see http://serverfault.com/a/339899/79266 and http://deranfangvomende.wordpress.com/2009/12/28/a-primer...
Fedora and LVM
Posted Nov 1, 2012 17:44 UTC (Thu) by nix (subscriber, #2304) [Link]
Fedora and LVM
Posted Nov 1, 2012 21:32 UTC (Thu) by agk (guest, #23332) [Link]
pvmove uses mirrors, not snapshots.
It works by setting up temporary mirrors for the kernel to sync the data between the old and new locations.
Fedora and LVM
Posted Nov 1, 2012 22:29 UTC (Thu) by nix (subscriber, #2304) [Link]
Fedora and LVM
Posted Oct 31, 2012 23:32 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
But my main beef with LVM is and has been since years that it's assembly is just broken and wrong. They assume that during boot there was a time where all devices have shown up, and which point they can invoke vgchange -ay, and that's the only time where they need to enumerate devices. But that's really not how things work these days, and haven't been working in the last decade or so. Hardware devices show up all the time, and we do not know when all connected devices have been detected, so in the boot process we don't actually know when we could invoke "vgchange -ay". Also, harddisks in times of USB and iSCSI show up at any time, depending on network status and their own initialization time and there are no general rules about when initialization has to be complete. The way distributions hack around the fact that they don't know when to invoke vgchange -ay is by pulling in udev-settle and the atrocity that is scsi-wait-scan. These hacks make things work for the "majority" of runs, and as long as you only have SATA disks and other pretty standard stuff. But the question is whether the "majority" is good enough where reliability is required, and whether limiting stuff to SATA and friends is such a good choice. But on top of that, it's just slow, since it basically is little more than just delaying the boot arbitrarily in the hope that all possible devices might have shown up when some time passes. Of course, if you are unlucky the delay is not sufficient, but still everybody has to endure the delay.
This issue has been known by the LVM folks since many years, and pointed out to them again and again. But nothing ever happened. Now, they say they'll soon have the "option" to make LVM work like any other hw daemon and actually wait on its own for precisely the devices it needs and not longer, thus not delaying the boot any bit longer than necessary. And they'll investigate if they can make that "option" default one day... At that speed I am sure that LVM well get discovery/assembly right only after the time it already has been replaced by btrfs... (btrfs in turn does get all this right: assembly is based of device plug events and a btrfs raid will delay the boot only exactly until the point where all devices it actually needs have shown up. btrfs raid is hence hotplug-safe, snappy at boot and absolutely reliable).
Anyway, the take-away is: LVM is the one major slowness in Fedora's boot. It also adds fragility where it shouldn't. And this hasn't changed in years. LVM is written they way hardware was in the 80's and 90's, but it is not how hardware has beeen working in the past 15 years or so.
Fedora and LVM
Posted Nov 1, 2012 0:31 UTC (Thu) by marcH (subscriber, #57642) [Link]
Fedora and LVM
Posted Nov 1, 2012 1:25 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Fedora and LVM
Posted Nov 1, 2012 14:02 UTC (Thu) by TRS-80 (guest, #1804) [Link]
Proxmox VE uses it to store virtual machine images, which it can then LVM snapshot for crash-consistent backups while the VM is running. Being a VM hypervisor, iSCSI is a natural choice to allow shared storage and migration between hosts. I have it running at work and it's pretty awesome.
Fedora and LVM
Posted Nov 2, 2012 19:06 UTC (Fri) by phiggins (guest, #5605) [Link]
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
Posted Nov 2, 2012 20:39 UTC (Fri) by nix (subscriber, #2304) [Link]
Fedora and LVM
Posted Nov 1, 2012 21:06 UTC (Thu) by agk (guest, #23332) [Link]
Semaphores are used only by the LVM/dm code for synchronisation with the udev rules that have to handle asynchronous uevents.
On a system using udev, after LVM/dm creates a device (or group of related devices) it needs to wait until udev has finished setting up those particular devices before it continues. This is done by having the last udev rule decrement a (per-transaction) semaphore to zero, which the blocked LVM/dm code waits for.
Fedora and LVM
Posted Nov 2, 2012 2:17 UTC (Fri) by mezcalero (subscriber, #45103) [Link]
Also, LVM could just subscribe to udev devices coming and going with libudev like everyvody else, and things would be good...
Fedora and LVM
Posted Nov 2, 2012 3:58 UTC (Fri) by agk (guest, #23332) [Link]
If only! We had lengthy discussions with the udev developers which led to the existing synchronisation mechanism.
Fedora and LVM
Posted Nov 1, 2012 22:36 UTC (Thu) by agk (guest, #23332) [Link]
If it had been easy, people would have submitted patches long ago:)
But the final piece of the assembly jigsaw is now passing our tests and should hit rawhide builds this week.
Fedora and LVM
Posted Nov 3, 2012 17:54 UTC (Sat) by Cato (guest, #7643) [Link]
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
Posted Nov 5, 2012 10:51 UTC (Mon) by nmav (subscriber, #34036) [Link]
> 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
Posted Nov 5, 2012 11:04 UTC (Mon) by dwmw2 (subscriber, #2063) [Link]
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
Posted Nov 6, 2012 13:33 UTC (Tue) by nix (subscriber, #2304) [Link]
Fedora and LVM
Posted Nov 6, 2012 16:19 UTC (Tue) by admax88 (guest, #75035) [Link]
Fedora and LVM
Posted Nov 6, 2012 16:45 UTC (Tue) by nix (subscriber, #2304) [Link]
Fedora and LVM
Posted Nov 6, 2012 16:52 UTC (Tue) by admax88 (guest, #75035) [Link]
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
Posted Oct 31, 2012 18:50 UTC (Wed) by paulj (subscriber, #341) [Link]
Without LVM, I'd have to do the upgrades in place. With the risk of being fscked if it goes wrong. (Yes, I should burn recovery CDs in advance - Yum upgrade fails catastrophically infrequently enough that I often don't, but frequently enough though that I have lost day+ to reinstall and reconfigure more than once).
Fedora and LVM
Posted Oct 31, 2012 18:54 UTC (Wed) by paulj (subscriber, #341) [Link]
If LVM snapshots could be promoted to writeable LVs, this process would be even easier. There doesn't seem be a way though. Since Solaris switched to ZFS and IPS, it does upgrades this way I think - through writeable snapshots.
Fedora and LVM
Posted Oct 31, 2012 20:11 UTC (Wed) by dtlin (subscriber, #36537) [Link]
Not sure what you mean by "writable LV" – LVM snapshots are already writable. If you want an wholly independent LV – perhaps you could just copy the snapshot to a new LV.
lvconvert --merge merges a snapshot back into the origin, for when you only want the snapshot's contents and not the origin's anymore.
(Hypothetically, at least. I've not yet tried it myself.)
Fedora and LVM
Posted Oct 31, 2012 22:28 UTC (Wed) by paulj (subscriber, #341) [Link]
Thanks :)
Fedora and LVM
Posted Nov 1, 2012 12:10 UTC (Thu) by Cato (guest, #7643) [Link]
Seriously, do a lot of testing before you rely on LVM snapshots. Or just use btrfs.
Fedora and LVM
Posted Nov 1, 2012 23:02 UTC (Thu) by agk (guest, #23332) [Link]
They are pretty robust nowadays: the last kernel race I can recall that could lead to incorrect data was found a few years ago now.
But they are not designed to be efficient if they grow large or if you have many of them; and make sure they never run out of space (use the snapshot_autoextend* lvm.conf settings / --monitor y / dmeventd).
Fedora and LVM
Posted Oct 31, 2012 21:02 UTC (Wed) by dlang (guest, #313) [Link]
works very well, no LVM needed.
I've also been bit my LVM and mount by UUID several times (did you know that mounting by UUID doesn't work if you have too many drives in your system? at least on some distros)
Fedora and LVM
Posted Nov 1, 2012 3:41 UTC (Thu) by faramir (subscriber, #2327) [Link]
That's fine for a fresh install. I believe the use case was for a easily revertable upgrade. Not the same thing.
Fedora and LVM
Posted Nov 7, 2012 13:00 UTC (Wed) by emmi3 (subscriber, #62443) [Link]
- 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
Posted Nov 7, 2012 18:26 UTC (Wed) by faramir (subscriber, #2327) [Link]
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.
Fedora and LVM
Posted Nov 2, 2012 7:45 UTC (Fri) by Cato (guest, #7643) [Link]
There's a simple non-LVM approach I've used a lot, which is to create two root FS partitions - install your current distro on one, then do 'rsync -avH' from one to the other, boot into that one, and do the upgrade there.
Or simply use a good backup tool to make a backup first - a 2TB drive is not much over $100 these days, just use rsnapshot or your preferred backup tool. If you run rsnapshot daily, it will complete very quickly on a root FS that doesn't change very much, and you can then easily do file-restores and inter-day comparisons of config files (not quite as nice as etckeeper but pretty good).
Once btrfs is more mature, its snapshots look really nice, and much faster than LVM's. Of course, backups are a really good idea either way.
Fedora and LVM
Posted Nov 1, 2012 23:55 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.
Fedora and LVM
Posted Nov 1, 2012 23:58 UTC (Thu) by Tobu (subscriber, #24111) [Link]
That was meant as a reply to dashesy, sorry.
Fedora and LVM
Posted Nov 2, 2012 0:19 UTC (Fri) by dlang (guest, #313) [Link]
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)
Fedora and LVM
Posted Nov 2, 2012 0:46 UTC (Fri) by Tobu (subscriber, #24111) [Link]
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?
Fedora and LVM
Posted Nov 2, 2012 1:13 UTC (Fri) by dlang (guest, #313) [Link]
Fedora and LVM
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.
Fedora and LVM
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).
$ 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"
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.
Fedora and LVM
Posted Oct 31, 2012 17:59 UTC (Wed) by wagerrard (guest, #87558) [Link]
The semantics of the partitioner have changed, as well. It talks about "reclaiming space" when it appears to mean creating a new partition table. How to go about that is not, to my thinking, made terribly obvious in the interface.
Looking forward to the Beta. This looks like a very nice release, Anaconda issues or no.
Fedora and LVM
Posted Oct 31, 2012 18:34 UTC (Wed) by dashesy (guest, #74652) [Link]
Fedora and LVM
Posted Oct 31, 2012 18:46 UTC (Wed) by marcH (subscriber, #57642) [Link]
Fedora and LVM
Posted Oct 31, 2012 20:02 UTC (Wed) by nteon (subscriber, #53899) [Link]
Fedora and LVM
Posted Oct 31, 2012 22:37 UTC (Wed) by marcH (subscriber, #57642) [Link]
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]
Fedora and LVM
Posted Nov 1, 2012 7:56 UTC (Thu) by marcH (subscriber, #57642) [Link]
Fedora and LVM
Posted Nov 1, 2012 21:34 UTC (Thu) by mstefani (guest, #31644) [Link]
Fedora and LVM
Posted Nov 1, 2012 23:55 UTC (Thu) by marcH (subscriber, #57642) [Link]
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]
/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]
Fedora and LVM
Posted Nov 1, 2012 21:01 UTC (Thu) by josh (subscriber, #17465) [Link]
Several encrypted partitions with one password and derived keys
Posted Nov 7, 2012 13:24 UTC (Wed) by emmi3 (subscriber, #62443) [Link]
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]
Fedora and LVM
Posted Oct 31, 2012 22:28 UTC (Wed) by kris.shannon (subscriber, #45828) [Link]
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]
Fedora and LVM
Posted Nov 1, 2012 12:42 UTC (Thu) by ricwheeler (subscriber, #4980) [Link]
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]
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]
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]
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]
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]
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]
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.
Fedora and LVM
Posted Oct 31, 2012 19:03 UTC (Wed) by drag (guest, #31333) [Link]
Now if your having a server setup then there is good reasons for it, but you are not going to be u sing the defaults anyways. So whether or not LVM is on by default is really of little impact.
Fedora and LVM
Posted Oct 31, 2012 20:18 UTC (Wed) by nix (subscriber, #2304) [Link]
I'm not sure that's always true.
Fedora and LVM
Posted Nov 1, 2012 0:52 UTC (Thu) by butlerm (subscriber, #13312) [Link]
That is a weakness in the filesystem that shouldn't require hard partitioning to resolve. It would make a lot more sense for a filesystem to be able to place files from different directory trees into internally independent allocation groups, such that a corruption in one of them would be no more likely to take another down than if they were in separate partitions.
That would be one way to radically speed fsck times as well.
Fedora and LVM
Posted Nov 1, 2012 17:55 UTC (Thu) by nix (subscriber, #2304) [Link]
With entirely independent filesystems, this problem goes away -- and moving *that* down into the filesystem is redundant, because we already have the ability to do just the same thing by making more than one filesystem.
Fedora and LVM
Posted Nov 1, 2012 18:43 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]
/home will always be on a partition with a given probability of failure.
Whether or not /var is on a separate partition does not seem like it would much affect probability of the fs metadata for /home getting corrupted.
I suppose /var may get written to more frequently (and thus increasing the chance of messing up the fs metadata), but on a desktop system, I would think the difference in the rate between which /home and /var is written is not that great.
And I haven't ever had trouble upgrading a system with a single partition (another common reason given).. installing a brand-new OS, yes.. upgrading no.
Fedora and LVM
Posted Nov 1, 2012 22:31 UTC (Thu) by nix (subscriber, #2304) [Link]
Writes to /home are relatively rare by comparison (even for me, with subscriptions to dozens of mailing lists all going into nnml spools under /home).
Fedora and LVM
Posted Nov 2, 2012 0:25 UTC (Fri) by ssmith32 (subscriber, #72404) [Link]
Much better than the hand-waving I've heard before.. ;)
Fedora and LVM
Posted Nov 2, 2012 17:31 UTC (Fri) by nix (subscriber, #2304) [Link]
Fedora and LVM
Posted Nov 1, 2012 4:21 UTC (Thu) by nickbp (guest, #63605) [Link]
Fedora and LVM
Posted Oct 31, 2012 19:45 UTC (Wed) by mmcgrath (guest, #44906) [Link]
My anaconda don't want none of those LVM Lun's.
"""
sorry, couldn't resist.
Fedora and LVM
Posted Oct 31, 2012 23:50 UTC (Wed) by mitchskin (guest, #32405) [Link]
The second reason is because of an awkward experience I had with it when I upgraded a laptop to a larger hard drive. I installed a fresh fedora installation with LVM on the new drive (since the HD upgrade was an opportunity for a clean fedora upgrade). Then I put the old drive into a USB enclosure to copy my /home LV to the new drive. But, since both drives had physical and logical volumes with the default names, that left me with multiple volumes with the exact same names. I've forgotten what I had to do to straighten things out, but it took much more R'ing of The FM than I had expected.
Fedora and LVM
Posted Nov 1, 2012 1:15 UTC (Thu) by PaulWay (guest, #45600) [Link]
Flexibility.
Sure, you can always do equivalent operations using raw partitions to the standard uses of LVM - setting up new partitions after your initial install, extending partitions, moving entire partitioning systems to new disks without downtime, etc. But they're painful, low-level operations that require a lot of hassle and are fraught with the possibility of adgering your entire system. Get one partition number wrong, forget that some numbers are written in 512-byte sectors and others in 2048-byte blocks and still others in 1024-byte kilobytes, and you might as well say goodbye to your system and start again.
Yes, you can use special graphical tools to reduce the likelihood of error on some of these things. LVM has one of those too.
Yes, a competent sysadmin can work around all these issues. LVM makes all of that easier.
Yes, if you know what you're doing you can set up your system with a spare set of partition entries just in case. But LVM saves you from having to know in advance that you might, at some point, need a second root partition or whatever.
Yes, the 'normal user' might not see those things. And the 'normal user' might never see a bash prompt, but we still install bash because of all the other uses of it.
LVM provides flexibility, future-proofing, and makes complicated operations simple.
I see lots of packages - systemd, LVM, SELinux - where there are plenty of vocal anecdotes of people who didn't understand it and disabled it and now never use it. I also see lots of anecdotes of people who swear off using AMD processors, or Seagate hard drives, or Asus motherboards, or whatever, because of that one time that they got hurt by some weirdness that they didn't understand at the time. This is magical thinking, people. Learn the new systems, rather than stepping away from them. Question your habits, rather than being a slave to them.
(Unfortunately for me, I installed F18 alpha at a stage where LVM didn't even seem to be offered as a partitioning option.)
Have fun,
Paul
Fedora and LVM
Posted Nov 2, 2012 0:23 UTC (Fri) by marcH (subscriber, #57642) [Link]
After reading the whole thread again, it's becoming very clear that any disk indirection layer like LVM is a "mobile phone-like" technology: people who never really used any of its features still don't see the point, while the people who got used to it can never go back.
Very same thing with Decentralized VCS.
This is of course independent of the quality of LVM as a specific product instance.
Fedora and LVM
Posted Nov 2, 2012 6:38 UTC (Fri) by cmccabe (guest, #60281) [Link]
Here's why:
* I often move my old partitions to a new Linux distro. Since the initrd / initramfs / etc code gets rewritten approximately every release, porting a complex setup is painful. On the other hand, just mounting a partition is easy.
* If you use something like RAID0 (I forget what LVM calls it), and one drive fails, all of your data is gone. "Too big to fail," unfortunately doesn't apply to volume groups. I'm sure there's a way to RAID5 it, and so forth, but then you have to start worrying about things like whether the drives are the same size, what is the correct stripe size to use, whether write barriers are fully supported on your configuration, and so forth. Again-- if you value your time, simple is better.
* If I really need to change the size of an ext3, ext4, etc. partition, the gparted boot disk can do it easily. I can even move partitions with dd or rsync (although that is rarely necessary.)
* Sometimes I even have to give more space, or take space away from, the OS of the Beast (yes, I still have one computer that dual-boots.) LVM can't help me with this-- in fact, it hurts severely, because gparted can't resize a partition which LVM is managing. So if I forget to uncheck the LVM install checkbox on my dual-boot PC, and I need to shrink the Windows partition, I'm screwed.
LVM makes more sense in a server environment, I think. Of course, even in a server environment, you often have things like RAID cards doing this kind of thing for you. Like everything else in storage, at the end of the day, it really depends on your use case.
Fedora and LVM
Posted Nov 2, 2012 7:24 UTC (Fri) by dlang (guest, #313) [Link]
Even if you are running on bare hardware, the trend is strongly towards either using network storage, or just reimaging the system if you have something as major as partitioning wrong.
on desktop/laptop systems, there aren't a lot of reasons for doing anything other than 'one big partition' (although I modify this to two small partitions for / and everything else for /var, with /home being a link into /var to make major OS changes easier)
Yes, you can make lots of small partitions and leave space unallocated to add later, but the odds of that being better than just using the entire disk as one partition are pretty low (especially for the average user)
Fedora and LVM
Posted Nov 2, 2012 12:02 UTC (Fri) by marcH (subscriber, #57642) [Link]
I understand you are "screwed" only because you cannot live without gparted.
Dual-boot is where I found LVM really, really kicks ass.
Realize you allocated too much space for Windows. Shrunk Windows and re-allocate what you just got to ANY other partition ANYWHERE on the system without moving anything. Simply cannot be done without an indirection layer like LVM.
Fedora and LVM
Posted Nov 2, 2012 23:37 UTC (Fri) by cmccabe (guest, #60281) [Link]
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
Posted Nov 12, 2012 3:01 UTC (Mon) by mfedyk (guest, #55303) [Link]
That may be a reason for the attempted change in f18. The ability to extend a partition online without needing lvm.
Fedora and LVM
Posted Nov 12, 2012 3:46 UTC (Mon) by steffen780 (guest, #68142) [Link]
Disclaimer: I have no idea if doing this is dangerous, but it has never bitten me.
Fedora and LVM
Posted Nov 3, 2012 18:14 UTC (Sat) by Cato (guest, #7643) [Link]
- 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
Posted Nov 4, 2012 11:28 UTC (Sun) by marcH (subscriber, #57642) [Link]
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
Posted Nov 3, 2012 18:10 UTC (Sat) by Cato (guest, #7643) [Link]
Fedora and LVM
Posted Nov 4, 2012 7:13 UTC (Sun) by Cato (guest, #7643) [Link]
Beginning LVM support in GParted
Posted Nov 15, 2012 17:37 UTC (Thu) by JanC_ (guest, #34940) [Link]
Fedora and LVM
Posted Nov 3, 2012 18:08 UTC (Sat) by Cato (guest, #7643) [Link]
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
Posted Nov 3, 2012 20:39 UTC (Sat) by dlang (guest, #313) [Link]
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
Posted Nov 1, 2012 1:42 UTC (Thu) by jwboyer (guest, #23296) [Link]
Actually, just to be clear, there is no such plan. There was a suggestion by someone that it be done, however it has no Feature page for it and FESCo has not reviewed anything along those lines. It might sound like splitting hairs, but Fedora as a distribution has no official plan to switch the default filesystem at this time.
Fedora and LVM
Posted Nov 1, 2012 15:21 UTC (Thu) by ricwheeler (subscriber, #4980) [Link]
There was an official Fedora Feature page to make btrfs the default, written up by Josef Bacik, that we killed at the last minute since the repair tool was not ready.
Have a look at:
https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs
The suggestion to make it the default was made by the btrfs people and will need a formal feature page (hopefully we will be able to leverage the old one to some extent).
Fedora and LVM
Posted Nov 1, 2012 20:08 UTC (Thu) by johannbg (guest, #65743) [Link]
Which means F19 would be used to do testing along with the F20 development cycle and the "official" switch be made in F20. ( F19 experimental/testing, F20 official unless of course if we wind up lengthening the release cycle to say 9 months... )
And I would not be surprised if the documentation community would want to do that as well to properly document it and related features.
With lessons learned from this release cycle I also expect the distribution feature process to be completely different in F19 from what it has been in previous release cycles.
Fedora and LVM
Posted Nov 1, 2012 12:16 UTC (Thu) by etienne (guest, #25256) [Link]
If I want two different Linux distribution (or two different versions) on the same disk I do not want to use two LVM versions to manage it.
Now if the distribution wants to use LVM on its own partition, there is no problem, but trying automagic there is risky.
Fedora and LVM
Posted Nov 2, 2012 11:18 UTC (Fri) by tom.prince (guest, #70680) [Link]
Fedora and LVM
Posted Nov 1, 2012 20:55 UTC (Thu) by johannbg (guest, #65743) [Link]
"The Fedora Engineering Steering Committee (FESCO) took up this issue and brought it to a vote on October 30. Full consensus was not to be found there either, but, in the end, FESCO voted in favor of the change back to the pre-F18 default. So, unless something gets derailed somewhere, the Fedora 18 will, like its predecessors, install and use LVM by default."
I brought it to their attentions since this was brought up *after*'we were in freeze and we in QA had been doing all our testing and decisions based on ext4 being the default filesystem.
The reason "Full consensus was not to be found" was because all the fesco members were unable to respond to that ticket in the time it was needed so once the majority was achieved we moved on.
If the newUI would have continued to offer users to hash or unhash lvm when the default partitioning was chosen ( as it did in F17 ) this discussion would never have taken place in the first place .
Having lvm as an default also destroys the ability for users to boot directly from an ext4 partition without initramfs which was entirely left out from "lvm as an default" discussion...
Fedora and LVM
Posted Nov 2, 2012 0:09 UTC (Fri) by Tobu (subscriber, #24111) [Link]
Having lvm as an default also destroys the ability for users to boot directly from an ext4 partition without initramfs which was entirely left out from "lvm as an default" discussion...
Why would this be supported? An initramfs provides a ton of flexibility and the cost is about zero, it's just a second file next to /vmlinuz.
Fedora and LVM
Posted Nov 2, 2012 10:03 UTC (Fri) by johannbg (guest, #65743) [Link]
Like majority of laptop/desktop users I have absolutely no need for the "advanced requirements" that initramfs brings so why would I want to use it? Why would I want to have and use additional bug layer on my system for no benefits to me at all?
Fedora and LVM
Posted Nov 2, 2012 15:15 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Fedora and LVM
Posted Nov 2, 2012 16:32 UTC (Fri) by johannbg (guest, #65743) [Link]
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
Posted Nov 2, 2012 17:35 UTC (Fri) by nix (subscriber, #2304) [Link]