Archlinux.fr [Forums]

Bonjour,

J'ai une question à laquelle je ne parviens pas à trouver de réponse en farfouillant sur Internet. Je ne comprends pas pourquoi la détection des volumes prend autant de temps au démarrage, et surtout, pourquoi dmeventd est si long à quitter lors de l'arrêt du PC.

J'ai deux PV (deux disques durs, des 7200tr/min) qui forment un seul VG. Sur ce VG, j'ai deux LV. Mais au démarrage, je vois que le service lvm2-pvscan met pas mal de temps à s'exécuter (entre 600 et 800ms), ce qui bloque certains services qui doivent démarrer après et qui en dépendent.
Une image sera sans doute plus parlante : http://i.imgur.com/lBCNI4E.png (j'ai encadré en orange les services concernés).

Pareil à l'arrêt de la machine, c'est long, ça prend plusieurs dizaines de secondes, c'est dmeventd, démarré par dm-event.service, qui prend bien son temps.

Est-ce qu'il est possible d'écrire une configuration afin d'éviter ces scans ? J'ai regardé les fichiers dans /etc/lvm/ (et plus particulièrement lvm.conf), mais je ne vois pas ce que je peux faire pour remédier à ça.
Les logs des services LVM2 ne montrent pas d'anomalies.

Merci d'avance.

Salut,

moins d'une seconde je trouve ça rapide ! Sur mon serveur, le scan met quasiment 4 secondes au démarrage. Par contre chez moi le service dm-event est désactivé, donc au shutdown je n'ai pas de souci. Est-ce toi qui l'a activé ?

Quatre secondes, quand même ! C'est vrai que je n'ai pas de point de comparaison, et moi ça me semblait long pour le peu à détecter.
8:17 correspond à /dev/sdb, et 8:33 correspond à /dev/sdc.

Non, dm-event est activé automatiquement par Systemd. Si je le maque, ça devient pire à l'arrêt, c'est lvm2-pvscan qui ne quitte pas, et là je dois attendre 1min 30 avant qu'il quitte.
Je pense qu'il est activé du fait qu'un de mes LV est en mode miroir ou RAID 1 (je ne sais plus lequel c'est, mais il me semble qu'en LVM il y a bel et bien une différence entre ces modes), mais ce qui m'embête c'est le temps qu'il met à quitter.

J'ai édité le service pour y ajouter des paramètres (-l -ddd) afin d'en comprendre davantage.
Le pastebin du boot est ici (j'ai gardé que la partie concernée), et celui de l'arrêt est là.

Tout ce que je note, c'est que : There are still devices being monitored. Refusing to exit. Oui, mais pourquoi justement ?

Le LV concerné est /dev/vg0/Donnees, qui est monté dans /home. Il est bien démonté...

Effectivement creer un lv en mode raid1 active le service dm-event. Maintenant pourquoi prend-il 10 secondes... mystère.

Concernant la différence mirror/RAID1, on trouve ceci dans /etc/lvm/lvm.conf :

Code : Tout sélectionner

        # Configuration option global/mirror_segtype_default.
        # The segment type used by the short mirroring option -m.
        # The --type mirror|raid1 option overrides this setting.
        # 
        # Accepted values:
        #   mirror
        #     The original RAID1 implementation from LVM/DM. It is
        #     characterized by a flexible log solution (core, disk, mirrored),
        #     and by the necessity to block I/O while handling a failure.
        #     There is an inherent race in the dmeventd failure handling logic
        #     with snapshots of devices using this type of RAID1 that in the
        #     worst case could cause a deadlock. (Also see
        #     devices/ignore_lvm_mirrors.)
        #   raid1
        #     This is a newer RAID1 implementation using the MD RAID1
        #     personality through device-mapper. It is characterized by a
        #     lack of log options. (A log is always allocated for every
        #     device and they are placed on the same device as the image,
        #     so no separate devices are required.) This mirror
        #     implementation does not require I/O to be blocked while
        #     handling a failure. This mirror implementation is not
        #     cluster-aware and cannot be used in a shared (active/active)
        #     fashion in a cluster.
        # 
        mirror_segtype_default = "raid1"

Donc mirror c'est l'ancienne méthode et RAID1 la nouvelle.

Par rapport à ton message, je tombe sur ça : http://comments.gmane.org/gmane.linux.lvm.general/12701 qui renvoie ici : https://bugzilla.redhat.com/show_bug.cgi?id=681582
Tu as des snapshots de défini ?

Dans ce cas là, je suppose que j'avais privilégié le mode "raid1".
Non, je n’utilise pas de snapshots. Par contre en lisant le rapport de bug que tu as mis, j'ai trouvé quelque chose, et il se trouve que si lui c'était lvm-monitor qui lui posait problème, c'est lié pour mon cas.
J'ai activé lvm2-monitor.service, et là, problème réglé (arrêt en 1 ou 2 secondes de la machine). Merci beaucoup.

Ça serait donc un léger bug de Systemd, vu que ce service devrait être activé automatiquement. Un systemctl enable lvm2-monitor.service résout ça.

Je mets le sujet en résolu. Je continue d'investiguer sur cette histoire de cache, j'ai une piste.

Concernant ce service, il y a une phrase (bien cachée) dans le wiki anglophone :

If you have LVM volumes not activated via the initramfs, enable the lvm-monitoring service, which is provided by the lvm2 package.

Côté dépendances de lvm2-monitor, on a :

Code : Tout sélectionner

Requires=dm-event.socket lvm2-lvmetad.socket
After=dm-event.socket dm-event.service lvm2-lvmetad.socket lvm2-activation.service lvm2-lvmetad.service

et lvmetad est activé (par exemple) via le hook lvm2. Comme ton vg ne contient que des données, je pense que tu n'as pas le hook lvm2 ?

On aurait donc deux cas :
- hook lvm2 actif -> Ceci active lvmetad et lvm2-monitor si nécessaire
- hook lvm2 non actif -> Il faut démarrer le service lvm2-monitor.

Non, je n'ai pas le hook lvm2 car, comme tu l'as dit, ce ne sont que des données personnelles donc non-vitales pour le système. La phrase que tu as trouvé est cachée dans la partie Snapshots ; je l'ai jamais lue.

Puis en vrai, j'ai actuellement un noyau custom, je n'ai même pas d'initramfs.

Pour cette histoire de cache, j'ai vu ceci :

Code : Tout sélectionner

cache_dir = "/etc/lvm/cache"

Ce répertoire n'existant pas, je l'ai créé. Mais après un redémarrage, il n'y avait toujours pas de fichier .cache dedans.

Au final, en lisant plus attentivement les commentaires, il est dit que c'est normal que ce fichier n'existe pas si obtain_device_list_from_udev est activé (ce qui est le cas par défaut). Mettre cette valeur sur 0 permet effectivement de créer le fichier .cache, mais ça ne semble plus plus rapide que ça (vu qu'Udev fait correctement son travail).
Bref, du coup tout semble normal de ce côté là, donc je pense que le temps que met lvm2-pvscan est déjà minimal.

Archlinux.fr [Forums]

[LVM2] Temps de boot et d'arrêt (Résolu)

[LVM2] Temps de boot et d'arrêt (Résolu)

Re: [LVM2] Temps de boot et d'arrêt

Re: [LVM2] Temps de boot et d'arrêt

Re: [LVM2] Temps de boot et d'arrêt

Re: [LVM2] Temps de boot et d'arrêt

Re: [LVM2] Temps de boot et d'arrêt

Re: [LVM2] Temps de boot et d'arrêt (Résolu)

Re: [LVM2] Temps de boot et d'arrêt (Résolu)