<div dir="ltr"><br>><br>> > Hi,<br>> ><br>> > Even though I've browsed through a lot of resources I haven't found any<br>> > satisfying answer to my question. I've been trying to minimize the booting<br>> > time in the user land on my embedded board, and when I run the classic<br>> > $systemd-analyze plot > plot.svg I saw that there is a non-negligible slot<br>> > of time in which all what systemd does is creating device units that were<br>> > discovered via udev.<br>> ><br>> > My problem is in the order in which these device units are created,<br>> > specially for the block device that contains my rootfs. What I noticed is<br>> > that when these device units are created, the one corresponding to my<br>> > rootfs blockdev partition is always the last one created, causing the other<br>> > services depending on it to wait much more than if the device unit was<br>> > created earlier.<br>> ><br>> > So, I would like to know if systemd follows a special order when creating<br>> > these units, and if yes, what can I do so the device unit of my rootfs<br>> > blockdev partition can be the first one created ?<br>><br>> The systemd-udev-trigger.service unit invokes "udevadm trigger" to<br>> trigger all devices that are already discovered by the kernel at that<br>> point. PID 1 listens to that and synthesizes .device units from all<br>> devices popping up. The order in which "udevadm trigger" triggers them<br>> is pretty much the order in which readdir() returns the devices when<br>> iterating through /sys/, i.e. basically undefined.<br>><br>> There's a github issue open somewhere where I proposed adding a new<br>> switch to "udevadm trigger" called --priorize-subsystem=… or so, which<br>> you can use to priorize on or more subsystems: any subsystems listed<br>> that way are triggered first. That way you could do "udevadm trigger<br>> --priorize-subsystem=block" to ensure block devices are triggered<br>> first (in fact, we probably should use this as default once we have<br>> the concept, given that the most relevant devices we wait for at boot<br>> are probably all block device). Would be happy to review/merge a patch<br>> for that.<br><br>Can't we already achieve this using the udevadm trigger filters i.e. --subsystem-match= ?<div><br>> Note that the order in which devices are triggered does not directly<br>> translate to the order in which devices actually are processed and<br>> make it through udevd and are picked up by PID 1. udevd runs rules for<br>> each device, and if those are slow and take a bit of time, this might<br>> delay delivery of the events to PID 1. However, there's certainly some<br>> relationship here: if certain devices are the ones we start processing<br>> first thy are likely also the devices where we finish processing them<br>> first, even if there's no strict guarantee for that.<br><br>I also like to mention that even if the block device is triggered earlier in systemd-udev-trigger.service (using the 

 --subsystem-match=

), sometimes the creation of the corresponding device unit is delayed. I noticed a delay of  0.8 to 1.5 seconds

 between the time systemd-udev-trigger.service became active and the time systemd started creating .device units.</div><div><br></div><div>I'm no expert in systemd and how PID 1 synthesizes the .device units from udev, but if I understood correctly your suggestion regarding prioritization, I think the implementation needs to be also on the systemd side. An example of such implementation can be the definition of a new udev keyword that one can use inside udev rules to mark devices that need to be prioritized by systemd.</div><div><br></div><div>--</div><div>Thank you for your reply, I appreciate it.</div></div>