Fedora 16 beta vice Knoppix

Jef Spaleta jspaleta at gmail.com
Wed Oct 5 18:24:24 UTC 2011

On Wed, Oct 5, 2011 at 9:22 AM, JB <jb.1234abcd at gmail.com> wrote:
> Here it is.

No..that's not it.. that is the starting point necessary to understand
the udev differences between the two systems. It is not a dissection.

To understand what is happening with udev across those systems you
have to look really close at the udev rules and the scripts being
fired by the rules to make a comparison about the number of udev
events which udevd is
trying to deal with before settle returns.  For all I know knoppix
delibrately ships with a very different udev rule set to keep udev
settle fast. I'm sure someone will correct me if I'm wrong but I think
a udev with no rules to parse will settle faster than a udev with many
rules that need to be parsed, and the details of the rule construction
will also matter, as will which modules are loaded in initrd I
believe. How many udev events is Knoppix actually processing on your
hardware? How many events is Fedora Live processing on the same
hardware? I'm pretty sure the number of events to process depends a
lot of the ruleset. And how much of the time parsing rules is bound up
with slow seek performance and unoptimized file layout?  Are you doing
spinning media for your comparisons or usb?

The fact that the udev init script that you pasted calls
/lib/udev/write_dev_root_rule script, which we don't provide at all is
already an indication that things are very different in terms of udev
configuration across the systems.    What other differences are
lurking _just_ in the udev config in Knoppix? My point is, this is not
an apples to apples comparison of sysinit versus systemd...not by a
long shot.  To understand why udevadm settle is taking longer in our
stack you have to ask some very detailed questions about the udev
configuration differences...including ruleset details such as timeouts
in each rule being parsed..and not just the master overriding timeout
that can be given for the settle command.


More information about the devel mailing list