Antw: [EXT] Re: device unit files

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 13.04.2022 um 17:38
in
Nachricht <YlbufcsF05NFQiUt@gardel-login>:
> On Di, 12.04.22 14:38, Elbek Mamajonov (emm.boxinuse@xxxxxxxxx) wrote:
> 
>> On graph I have mmcblk.device taking 1.624s. From the point that
>> this partition is where my rootfs lies, and systems does remounting
>> of rootfs, I did look up for systemd-remount-fs.service, it took
>> 231ms, and systemd-udev-trigger.service, as you suggested, it took
>> 517ms to become active. But even after systemd-udev-trigger.service
>> becomes active there is about 800ms for mmcblk.device to become
>> active. Are those services related to the activation of the
>> mmcblk.device? Can I consider those 231ms and 517ms as a part of the
>> activation time of the mmcblk.device? How can I debug udev in this
>> case?
> 
> "systemd-udev-trigger.service" might take a while before it completes,
> since it triggers basically all devices in the system.
> 
> It might be worth triggering block devices first. With upcoming v251

What is the expected benefit? On bigger servers with hundreds of disks this
may take longest.

> we actually will do that by default. But until then you could extend
> the service by first issuing "udevadm trigger -sblock", before the
> rest.
> 
> udev will announce devices to the system (and thus also PID1) once it
> probed the device. it does this based on rules, and the default rules
> will run blkid on the device, to see what's on it (i.e. to extract fs
> label/uuid, …). maybe that's just terribly slow on your device?
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin