On Wed, 15.05.13 12:55, Richard W.M. Jones (rjones@xxxxxxxxxx) wrote: > On Wed, May 15, 2013 at 01:36:57PM +0200, Lennart Poettering wrote: > > On Tue, 14.05.13 20:43, Adam Williamson (awilliam@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
