Fedora 16 beta vice Knoppix

[Lennart Poettering]

On Tue, 04.10.11 19:40, Adam Williamson (awilliam at redhat.com) wrote:

> 
> On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote:
> > On Tue, Oct 4, 2011 at 3:32 PM, JB <jb.1234abcd at gmail.com> wrote:
> > >  13837ms udev-settle.service
> > >  11392ms plymouth-start.service
> > 
> > 
> > if you use the plot option instead of blame option and produce the svg
> > of the service timing you get a better feel for what Lennart was
> > talking about with regard to the udev settle being problematic.
> > 
> > I'll try to break it down for you. Keep the following in mind when you
> > look over the svgs produced in susequent testing.
> > 
> > udev-settle.service essentially calls udevadm settle and that's all it does.
> > udevadm settle  takes FOREVER (15 seconds) to return during boot up on
> > my live media run  But its returns more quickly on on F15 install (3
> > seconds). I'll check a full F16 beta install soonish.
> 
> And remember that all udevadm settle does is wait for the udev event
> queue to empty.
> 
> So essentially all that's going on here is 'wait for udev to be done',
> which is a fairly sensible prerequisite for all manner of other bits of
> boot.

Nah, this is not a sensible prerequisite. User code should *not* have to
wait for udev to be settled.

They key message Kay and I and everybody else involved in udev/systemd
and related technologies want to get into everybodies head is that
applications should never ever expect that "everything is settled",
since that is simply not possible (i.e. USB init times are unbounded --
so how do you know that the usb disk fully initialized when you settled
the udev queue?) and all attempts to fake that are major sources of
slowness at boot (to deal with USB and stuff people basically just wait
a couple of seconds, which doesn't fix the problem, just tapes over it).

Or in other words: "udev settle" is a hack and is not part of our boot
anymore -- unless LVM pulls it in. And the fact that it pulls it in is
sad, and has been a constant source of complaining from us to the LVM
folks over the years.

They major point to make here is that all components of the system
should wait exactly as long as they have to and not longer. More
specifically: they should wait for the specific hardware they are
needing but not any longer. Example: when mounting the file systems
systemd will wait exactly until the point all devices listed in
/etc/fstab have shown up -- but not any longer before continuing.

And again, in short words:

"udev settle" is a hack. Only broken code needs it. It has no place in a
modern system.

> The reasons why udev takes a while to be 'done' are more interesting and
> Lennart went into some of them.

It is completely fine if some probing done by udev rules takes a long
time. It's not just fine, it's even expected. For example, I have a 3G
card in my laptop I don't use. Since it has no SIM card it takes about
8s seconds to probe (i.e. the firmware finds it funny to reply with an
8s delay to AT commands if no SIM card is in the card). Now, there's no
sensible way around this, since the the hw just takes that long to
probe. As long as these 8s are spent in the background they shouldn't
matter at all. Except that LVM requires settling of all devices, and
hence simply enabling LVM means my boot is delayed for a whole 8s. Now
thankfully, I opted out of LVM when I installed Fedora on my
machine. That way the 8s probing of the modem continues in the
background long after gdm is already up.

That's why I mentioned in that earlier mail to ajax that I am not
concerned that EDID takes so long: because it is OK. What isn't OK is
that LVM has to wait for EDID and for my 3G modem probing to complete,
and thus delays our entire boot.

LVM needs to be ported to listen to hotplug events, and make use of
devices as they show up, instead of expecting that all hardware has
already shown up and has been probed before LVM is started. For a number
of reasons: to not slow down the boot artificially, to fix the
enumeration race and become fully compatible with today's storage
technology that is much more dynamic than 10 years ago, and to become
robust.

Please, don't claim that "udev settle" was a sensible prerequisite. It
isn't. It has no place in today's dynamic hardware.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.