Qu'est-ce que lvmetad et pourquoi voudrais-je ou dois-je l'utiliser?
J'ai un serveur Gentoo avec LVM fonctionnant au-dessus d'une matrice RAID que j'utilise depuis un certain nombre d'années. Récemment, j'ai mis à niveau LVM vers 2.02.109 (je ne me souviens pas de la version précédente) et j'ai reçu un message lors de la mise à niveau:
* Make sure to enable lvmetad in /etc/lvm/lvm.conf if you want
* to enable lvm autoactivation and metadata caching.
Je comprends que je peux l'activer en définissant use_lvmetad = 1 dans /etc/lvm/lvm.conf.
Mais pourquoi aurais-je besoin d'une telle fonctionnalité? Ma compréhension est que cela fonctionne avec les règles udev pour garder l'état LVM dans un cache afin que les outils LVM n'aient pas besoin d'analyser les volumes pour obtenir ces informations. Est-ce juste que ma petite baie ne peut pas bénéficier de ce genre de fonctionnalité? Dans quelles circonstances pourrais-je vouloir/devoir l'utiliser?
La description
Depuis la page de manuel lvmetad :
lvmetad est un démon de mise en cache des métadonnées pour LVM. Le démon reçoit des notifications des règles udev (qui doivent être installées pour que LVM fonctionne correctement lorsque lvmetad est utilisé). Grâce à ces notifications, lvmetad dispose d'une image à jour et cohérente des groupes de volumes disponibles dans le système. Par défaut, lvmetad, même s'il est en cours d'exécution, n'est pas utilisé par LVM. Voir lvm.conf (5).
Un examen plus approfondi mérite une autre définition. Wikipedia déclare:
Un système de fichiers de journalisation est un système de fichiers qui garde une trace des modifications qui seront apportées dans un journal (généralement un journal circulaire dans une zone dédiée du système de fichiers) avant de les valider dans le système de fichiers principal. En cas de panne du système ou de panne de courant, ces systèmes de fichiers sont plus rapides à remettre en ligne et moins susceptibles d'être corrompus.
Raisonnement
Je n'entrerai pas dans une explication détaillée de LVM, car l'OP en comprend déjà les avantages. En tant que tel, je vais seulement expliquer pourquoi la journalisation a été ajoutée. Les anciennes versions de LVM n'avaient pas de démon de journalisation, ce qui signifie que si le système tombait en panne, le seul journal qui pouvait être utilisé se trouvait sur le volume physique (disque dur). Cela crée un problème lorsque le volume logique s'étend sur plusieurs extensions sur des groupes de volumes logiques qui s'étendent sur plusieurs volumes physiques.
Si la moitié d'une transaction de journal existe sur un volume physique et que l'autre moitié existe sur un autre volume physique, le journal transactionnel ne peut pas valider les modifications sur les deux volumes physiques, car les volumes physiques ne comprennent pas qu'ils sont partie d'un groupe de volumes , car le journal des transactions n'existe que dans le volume physique.
C'est là que le nouveau démon entre en jeu. Désormais, au lieu d'un journal de journal pour chaque volume physique, LVM peut créer un journal de journal et créer une section pour celui-ci dans le groupe de volumes, qui est réservé à la journalisation uniquement. Après cela, le journal des transactions complet peut être trouvé et relu au niveau du groupe de volumes.
De ce lien :
Normalement, chaque commande LVM émet une analyse de disque pour trouver tous les volumes physiques pertinents et lire les métadonnées de groupe de volumes. Cependant, si le démon de métadonnées est en cours d'exécution et activé, cette analyse coûteuse peut être ignorée ... Cela peut économiser une quantité importante d'E/S et réduire le temps requis pour terminer les opérations LVM, en particulier sur les systèmes avec de nombreux disques.
Vous l'exécuteriez donc pour des performances accrues de gestion LVM et d'opérations d'état, au détriment des performances de démarrage et d'une complexité accrue. Le niveau d'augmentation des performances est plus élevé lorsqu'il y a plus de disques dans le système.