On Thu, 12.05.11 09:01, Scott James Remnant (sc...@netsplit.com) wrote: > On Mon, May 9, 2011 at 12:43 PM, Lennart Poettering > <lenn...@poettering.net>wrote: > > > > This means there are a large number of devices already known to the > > kernel > > > at the point that systemd starts, especially if you build the drivers > > into > > > the kernel for those devices. It's possible to get going straight away > > with > > > those devices. But relying on udevd tagging them means you end up waiting > > > around for udevd to start, and worse! since udevd doesn't apply rules to > > > existing devices on startup, you have to wait around for "udevadm > > trigger" > > > to be run. > > > > That's actually dead fast, and systemd picks up those devices as they > > show up. The trigger can hence finish after we already preceeded > > booting. In fact, with the new netlink actviation in newest udev and > > systemd we can start the trigger at the same time as udev itself. > > > > We cannot really mount file systems before their block devices have > > shown up and have been probed, and we exactly wait for that, and no > > longer. To do fsck/mount we need udev to have run for that device, > > there's no realistic way around that. > > > It isn't "dead fast" enough. > > The problem is that when you run udevadm trigger, it doesn't immediately > spawn 700 processes to handle the events. So you end up with situations > where input devices aren't available to X because the system is too busy > probing for filesystems, or loading sound card drivers.
We could optimize this in udev I guess. For example udev trigger could just pass to udev ahead of time how many devices it needs to probe so it could spawn a lot of processes right away, instead of slowly increasing the number of workers. That said I don't know how udev currently handles this. Maybe it already reacts fast enough for this. Kay knows if this mgiht be a problem. If this is really a problem we could probably also change the probing order in udevadm trigger, and probe certain subsystems earlier than others. (as has been suggested in another context already) > And we really *can* mount file systems before their block devices have been > probed (they show up as soon as the driver's loaded). Actually the probing > code is exactly the kind of code I would want to delay; filesystems can be > mounted by GPT ids which doesn't require the expensive block device > probing. I have my doubts that this would really cut it. I'd like to see hard data on this before we optimize here. > > udev isn't just about symlinks. It's about perms and primarily about > > meta data, and a lot of other stuff too. > > > perms are increasingly irrelevant due to ACLs, which your plans are moving > to systemd, no? udev continues to mark devices for ACL management. systemd will then apply the ACLs based on seat/session info. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
