Importance of LVM (was Re: Partitioning criteria revision proposal)

[drago01]

On Thu, Oct 25, 2012 at 11:09 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Thu, 2012-10-25 at 22:51 +0200, drago01 wrote:
>> On Thu, Oct 25, 2012 at 10:26 PM, Adam Williamson <awilliam at redhat.com> wrote:
>> > On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote:
>> >
>> >> BTW, on the topic of LVM specifically (whose importance we still haven't
>> >> really established): I did some archive-diving last week. We first went
>> >> to LVM-by-default all the way back in Fedora Core 3. There were two
>> >> reasons for doing this. The 'official' one was to make it easier to
>> >> expand the capacity of a system simply by adding another hard disk. The
>> >> less official reason was to get more testing of LVM, which was still in
>> >> its infancy at the time. Ever since then, we've stuck with the default
>> >> really just because it's always been there; until I started poking into
>> >> it, no-one really had a story for why LVM was default any more.
>> >>
>> >> Neither reason really applies much any more. LVM is much more mature
>> >> now, and in a way is yesterday's news, the Glorious Future maybe belongs
>> >> to btrfs. And we've finally hit the point in history where most people
>> >> don't run out of space on the hard disk that comes with their system,
>> >> and even when they _do_ run out of space, it's usually not with OS data
>> >> but with 'user data' that is much easier to spread across multiple disks
>> >> without using LVM. So I'm not sure we really have a convincing reason
>> >> any more to care especially about LVM.
>> >
>> > On this topic...Ric Wheeler came up with some fairly good arguments in
>> > favour of keeping the LVM default and proposed it on the anaconda list
>> > this morning (actually I think the post may not have been approved yet,
>> > but it'll show up soon). Since we're post-freeze now I summarized the
>> > debate into a bug report and nominated it for NTH:
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=870207
>> >
>> > I think it's still true to say that our *original* reasons for
>> > defaulting to LVM don't really hold any more, but Ric made some pretty
>> > decent *current* arguments for keeping that default until we switch to
>> > btrfs-by-default.
>>
>> What exactly does not hold anymore? Resizing partitions isn't that
>> common and not the primary use of LVM (you can do it without it and
>> most users won't).
>
> You can do it without LVM, but not as reliably (you're *more* likely to
> get into trouble resizing a raw ext4 partition than an LV) and with more
> limitations (the big one being you can't resize an ext4 partition from
> the front: so if you have a disk with 10GB / then 100GB /home, and you
> fill up /, you can't make /home smaller and use the additional space
> for /, because it can't be contiguous. All you can do is create a new
> partition after /home and bodge it up somehow, by mounting it as /var or
> something; much messier).
>
> 'most users won't' is hard to prove but likely true, but then, *some*
> users will, and isn't it nice that they have the ability to do it?

Yes but that can be said about pretty much anything.

>> It is still pretty much useless (as in the extra
>> features won't be used) for the average desktop / laptop installs.
>
> They're neat features, though, and they're available, and _some_ people
> can use them, and people who don't use them aren't hurt (except see
> below).
>
>>  For
>> most users all it does is slowing down the boot process (we should
>> stop adding crap to the default boot process because someone might
>> need it on some obscure case).
>
> Does LVM slow down boot significantly? Do you have numbers for that? I
> hadn't heard that factor cited in the debate so far. Could you add it to
> the bug if you have solid data? It'd be useful input.

I don't have current numbers but it adds a synchronisation point (i.e
breaks a fully parallel bootup) let me just quote this
(http://0pointer.de/blog/projects/blame-game.html):

"Let's have a closer look at the worst offender on this boot: a
service by the name of udev-settle.service. So why does it take that
much time to initialize, and what can we do about it? This service
actually does very little: it just waits for the device probing being
done by udev to finish and then exits. Device probing can be slow.
[..]  So, why is udev-settle.service part of our boot process? Well,
it actually doesn't need to be. It is pulled in by the storage setup
logic of Fedora: to be precise, by the *LVM*, RAID and Multipath setup
script. These storage services have not been implemented in the way
hardware detection and probing work today: they expect to be
initialized at a point in time where "all devices have been probed",
so that they can simply iterate through the list of available disks
and do their work on it. However, on modern machinery this is not how
things actually work: hardware can come and hardware can go all the
time, during boot and during runtime. For some technologies it is not
even possible to know when the device enumeration is complete
(example: USB, or iSCSI), thus waiting for all storage devices to show
up and be probed must necessarily include a fixed delay when it is
assumed that all devices that can show up have shown up, and got
probed. In this case all this *shows very negatively in the boot
time*: the storage scripts force us to delay bootup until all
potential devices have shown up and all devices that did got probed"

>> Those who know about the extra features
>> and want to use them will enable it anyway regardless on what we set
>> as defaults.
>
> It's somewhat harder to change in newUI than oldUI because there isn't
> just a checkbox for it, and I don't think the designers want there to be
> one. To change from the default (whatever the default is) you have to go
> through custom partitioning.

True but OTOH if you know about LVM chances are that you aren't just
clicking next during the installation but review / modifiy every
spoke.

> Also, this doesn't catch the case of someone who's never used LVM, does
> an install of Fedora, notices that it uses LVM, and gets interested
> about it and finds out the neat stuff it can do. That's not a terribly
> unusual use case for Linux distros in general, is it? We all start out
> as newbies after all...I often find out about cool stuff 'by accident'
> in this way, just by stumbling across it.

He might also find find out that it is useless for him and that he
cannot (easily) remove it without reinstalling. I am not saying LVM
does not have use cases where it makes sense. I just don't think it
makes sense as a default.