when startup delays become bugs

[Lennart Poettering]

On Wed, 15.05.13 12:55, Richard W.M. Jones (rjones at redhat.com) wrote:

> On Wed, May 15, 2013 at 01:36:57PM +0200, Lennart Poettering wrote:
> > On Tue, 14.05.13 20:43, Adam Williamson (awilliam at redhat.com) wrote:
> > >            356ms systemd-udev-settle.service
> > 
> > This is exlusively LVM's fault. There's really no need to ever have that
> > in the boot unless you run LVM. 
> > 
> > On many machines LVM is the primary reason why things are slow. I can
> > only recommend everybody to not install on LVM if you can. It's a real
> > shame that LVM hasn't gotten their things together still, after all
> > those years. 
> 
> Is there a constructive summary anywhere of what LVM needs
> to do / change?  This problem affects libguestfs too.

It should subscribe to block devices coming and going and then assemble
things as stuff appears. Right now it expects to be called at a point in
time where everything that might show up has shown up. Of course, that's
not how modern hardware works (everything is hotpluggable now, hw gives
no guarantees when it shows up and we don't have any idea what might
still come hence), and requires pulling in of udev-settle. It requires
us to delay the boot, in order to keep the promise of "everything has
shown up now" to LVM, which happens to be a promise that we cannot
actually hold, since we don't know whether something is missing...

LVM should subscribe to udev events like any other daemon, and 
as soon as all devices it needs have shown up immeidately
assemble things. This would guarantee minimal boot times since we
would have to wait exactly for the devices that are actually needed, and
that's it. We wouldn't have to wait for devices we never know might
appear and that nobody actually needs.

If it wasn't for LVM we'd have removed the udev-settle functionality
from udev already, since it's just broken, and slows down things too.

LVM of course has been broken like this for 5 years, and they know
that. And they did nothing about it. And that's so disappointing...

(Of course, btrfs got assembly right from day 1: it will assemble disks
exclusively via udev events and as soon as a device is complete it is
made available to the OS. The btrfs folks understood how modern hardware
and storage technology works, the LVM folks not so much I fear...)

> > I am hoping for the day LVM gets kicked out of the default install. Oh
> > btrfs, why are you still not around?
> 
> I Want To Believe in btrfs, but unfortunately it's still excessively
> buggy.  It's actually got worse in Rawhide recently -- it reliably
> fails in mkfs.btrfs :-(  I stopped bothering filing bugs about this
> because they just get ignored because Rawhide isn't "new enough" (they
> want us to retest everything on some non-upstream btrfs-next kernel).
> My colleague ran btrfs on his laptop and had daily crashes.  Last week
> he went back to ext4.

Well, it works fine for myself and for quite a few other folks I
know. I am pretty sure it's time to grow some, make this the default in
Fedora, and then fix everything popping up quickyl with the necessary
pressure. As it appears not having any pressure to stabilize btrfs
certainly doesn't work at all for the project...

Lennart

PS: I am very good at bitching about LVM. You can book me for your party
at very low rates!

-- 
Lennart Poettering - Red Hat, Inc.