[systemd-devel] udev took too long to start

[Kay Sievers]

On Wed, May 18, 2011 at 15:46, Chen Jie <chenj at lemote.com> wrote:
> 2011/5/18 Kay Sievers <kay.sievers at vrfy.org>:
>> On Wed, May 18, 2011 at 14:18, Chen Jie <chenj at lemote.com> wrote:
>>> 2011/5/18 Kay Sievers <kay.sievers at vrfy.org>:
>>
>>>> udev.service does usually takes no time. It's the settle that may
>>>> block for a longer time. In your chart it seems like a side-effect,
>>>> and the root-fsck seems suspicious. any idea what could take so long
>>>> here? Care to try without it?
>>> Just like you said in my test, see boot1.svg vs boot2.svg(touch
>>> "/fastboot" to skip fsck), under systemd v24.
>>
>> Yeah, much better. What's the reason it takes so long to fsck?
> Guess something like "filesystem mounted 33 times without check, check
> it", I enabled fsck and tested again(boot3.svg), it looks fine.

Good.

>>> BTW, In my test platform, udev.service will take ~1s even when fsck
>>> skipped, seems a bit long.
>>
>> Yeah, seems long, but may happen with a slow disk. What kind of box,
>> or rootfs type is that?
> It's a fuloong box[1] with ext4:
> """
> /dev/root on / type ext4 (rw,relatime,barrier=1,data=ordered)
> """
> How about startup time of udev.service on other platform?

Completely different! That's an Intel Core Duo 1.4 GHz laptop:
  systemd-analyze blame | grep udev
  87ms udev-trigger.service
  13ms udev.service

>> Care to provide the full output of:
>>  time udevadm test /class/block/sda1
>> ?
> real    0m0.146s
> user    0m0.084s
> sys     0m0.048s
> See udevadm_sda2.txt in detail.

It seems not slow. But it looks a bit weird. You are sure there is
nothing missing in the file?

We never call scsi_id, ata_id in your output, but get the links from it?
  udev_rules_new: rules use 153420 bytes tokens (12785 * 12 bytes),
29178 bytes buffer
  ...
  udev_rules_apply_to_event: LINK
'disk/by-id/scsi-SATA_SAMSUNG_HM121HCS12SJD0S208504-part2'
/lib/udev/rules.d/60-persistent-storage.rules:99

>> And what's hdparm.service that takes that long? It sounds wrong to
>> ever fiddle around with disks that way these days.
>>
> It comes from sysv-init script of my debian.

Yeah, kill it. It can only let things go wrong. The entire idea of
calling hdparm from udev rules is completely confused. That stuff
should never be done that way.

Kay