Je vous rassure, quand je parle de « frayeur », n’allez pas imaginer un bug sur LVM ou quoi que ce soit dans le genre. LVM est (et restera), l’un des logiciel les plus puissant et les plus fiables que je connaisse. Mais j’ai eu ce week-end une petite inquiétude…
La situation était la suivante. Un serveur de fichier avec un raid logiciel (mdadm), et un groupe de volume ne comprenant qu’un seul disque physique (PV), c’est à dire le raid lui même (/dev/md0). Ce groupe de volume n’ayant qu’un seul « disque » utilisant en réalité plusieurs « vrais » disques, j’avais, au moment de la création initiale, demandé l’écriture de deux copies des méta données au lieu d’une seule. Le PV était donc constitué de la façon suivante :
- meta-data LVM
- Données
- meta-data LVM
Et tout allait très bien jusqu’à ce qu’il faille agrandir le PV en question. (Ajout d’un nouveau disque dans le raid, puis mdadm –grow…). Au moment de lancer la commande pvresize, j’ai obtenu ce magnifique message : « too many metadata areas for pvresize ». Ouch.
Et oui, la seconde copie empêchait LVM d’étendre la partie « donnée » (et donc de créer de nouveau physical extend etc). C’est la qu’une (grosse) inquiétude s’est emparé de moi, car ce paramètre n’est pas modifiable à chaud. Il dépend des options de création du pv, au moment du pvcreate donc….
Heureusement, google trouva très vite la solution, parfaitement décrite dans la documentation, et que je ne recopie ici que pour me servir de pense bête. L’idée est la suivante : on sauvegarde la configuration, (emplacement des volumes logiques etc), on relance le pvcreate en ne demandant cette fois qu’une seule copie des meta-data, puis on ré-applique la configuration, en forçant bien l’ancien uuid. En terme de commande, cela donne :
- vgcfgbackup -v -f /some/file volumeGroup
- vgchange -an volumeGroup
- pvcreate -ff –metadatacopies 1 –restorefile /some/file –uuid UUID /dev/device
- vgcfgrestore -v -f /some/file volumeGroup
- pvresize /dev/device
Notez que la commande vgcfgbackup pourrait être remplacée par la simple copie du fichier de configuration présent dans /etc/lvm/backup. Notez aussi que pour pouvoir stopper le groupe de volume (vgchange -an), il faut bien évidement avoir auparavant démonter tous les systèmes de fichiers, ou ce qui pourrait utiliser les volumes logiques d’une façon ou d’une autre (cryptsetup…). Autre point important, ne vous trompez pas d’UUID. On parle bien ici de l’uuid du volume physique (PV), pas de l’UUID du groupe de volume.
Cette opération à parfaitement fonctionnée et contrairement à ce qui est indiqué dans la documentation elle me semble absolument sans risques (a condition que vous ne fassiez pas n’importe quoi bien sur..).
Comme d’habitude, je suis impressionné par ce formidable outil qu’est LVM. Comment faisait on avant ?
