Sais-tu comment le kernel fait pour estimer la durée de boot de l'UEFI ?
C'est systemd qui récupère l'information, pas forcément le kernel.
https://github.com/systemd/systemd/blob/600362aa11af5af90125aacc8ad7612a5cb80a68/src/shared/boot-timestamps.c#L22Il y a donc deux sources possibles :
- les tables ACPI (/sys/firmware/acpi/fpdt/boot/*, ou /sys/firmware/acpi/tables/FPDT + /dev/mem)
- le bootloader (en suivant
https://systemd.io/BOOT_LOADER_INTERFACE/), ce qui ne fonctionne probablement qu'avec systemd-boot (et sans hyperviseur, voir
https://github.com/systemd/systemd/blob/600362aa11af5af90125aacc8ad7612a5cb80a68/src/boot/efi/ticks.c#L17)
Sur les autres serveurs, peut-être que le firmware ne fournit pas de table FPDT (Firmware Performance Data Table).
fstrim peut prendre du temps, et c'est probablement lui qui fait que le device sda2 (SSD si j'ai bien compris) met temps de temps à démarrer. Ca ne devrait pas ralentir le montage ceci dit : il est exécuté en background, une fois le FS monté.
Le fstrim, c'est un peu bizarre de l'avoir au boot, et pas de manière régulière (une fois par semaine par exemple).
Ca pourrait ralentir les autres accès : le TRIM asynchrone n'est pas supporté par beaucoup de SSD SATA, et sur d'autres il a été désactivé pour cause de bugs (au moins à l'époque, seul Linux s'en servait, donc c'était moins testé).
Le formatage EXT4 date de 2016 (lors de l'installation d'Ubuntu server 14.04.5 LTS), j'ai fait un sujet quand j'ai acheté ce SSD : Le SSD de LaFibre.info
On peut comparer les options dans /etc/mke2fs.conf, et celles dans "dumpe2fs /dev/sda2 | grep features".
Mais sur le temps de montage, je ne vois pas grand chose à priori, à part si l'option "bigalloc" est activée (amélioration du temps de montage dans mke2fs 1.46.0 (
https://github.com/tytso/e2fsprogs/commit/59037c5357d39c6d0f14a0aff70e67dc13eafc84), ou le kernel 5.18 (
https://github.com/torvalds/linux/commit/eb7054212eac8b451d727bf079eae3db8c88f9d3)).
Voici le graphique systemd-analyze plot > plot.svg :
Je vois deux systemd-fsck, qui sont très rapides.
Le dev-sda2.device commence avant le dev-sda.device, donc je me demande si le début n'est pas simplement le moment où systemd commence à attendre la partition (si le disque est long a être détecté par le kernel, ...).
Le ifupdown-pre.service est long également, et se finit au même moment. Il faut "udevadm settle", donc il y a peut-être quelque chose qui prend du temps avec les événements de hotplug (à voir peut-être dans les traces kernel).