{"id":189,"date":"2011-11-04T13:31:00","date_gmt":"2011-11-04T13:31:00","guid":{"rendered":"http:\/\/hoper.dnsalias.net\/atdc\/index.php\/2011\/11\/04\/20111104mini-frayeur-avec-lvm\/"},"modified":"2011-11-04T13:31:00","modified_gmt":"2011-11-04T13:31:00","slug":"20111104mini-frayeur-avec-lvm","status":"publish","type":"post","link":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/2011\/11\/04\/20111104mini-frayeur-avec-lvm\/","title":{"rendered":"Petite frayeur avec LVM"},"content":{"rendered":"

Je vous rassure, quand je parle de \u00ab\u00a0frayeur\u00a0\u00bb, 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\u00e9tude…<\/p>\n

La situation \u00e9tait 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 \u00e0 dire le raid lui m\u00eame (\/dev\/md0). Ce groupe de volume n’ayant qu’un seul \u00ab\u00a0disque\u00a0\u00bb utilisant en r\u00e9alit\u00e9 plusieurs \u00ab\u00a0vrais\u00a0\u00bb disques, j’avais, au moment de la cr\u00e9ation initiale, demand\u00e9 l’\u00e9criture de deux copies des m\u00e9ta donn\u00e9es<\/a> au lieu d’une seule. Le PV \u00e9tait donc constitu\u00e9 de la fa\u00e7on suivante :<\/p>\n

    \n
  1. meta-data LVM<\/li>\n
  2. Donn\u00e9es<\/li>\n
  3. meta-data LVM<\/li>\n<\/ol>\n

    Et tout allait tr\u00e8s bien jusqu\u2019\u00e0 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 : \u00ab\u00a0too many metadata areas for pvresize\u00a0\u00bb. Ouch. <\/p>\n

    Et oui, la seconde copie emp\u00eachait LVM d’\u00e9tendre la partie \u00ab\u00a0donn\u00e9e\u00a0\u00bb (et donc de cr\u00e9er de nouveau physical extend etc). C’est la qu’une (grosse) inqui\u00e9tude s’est empar\u00e9 de moi, car ce param\u00e8tre n’est pas modifiable \u00e0 chaud. Il d\u00e9pend des options de cr\u00e9ation du pv, au moment du pvcreate donc….<\/p>\n

    Heureusement, google trouva tr\u00e8s vite la solution, parfaitement d\u00e9crite dans la documentation<\/a>, et que je ne recopie ici que pour me servir de pense b\u00eate. L’id\u00e9e 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\u00e9-applique la configuration, en for\u00e7ant bien l’ancien uuid. En terme de commande, cela donne :<\/p>\n

      \n
    1. vgcfgbackup -v -f \/some\/file volumeGroup <\/li>\n
    2. vgchange -an volumeGroup <\/li>\n
    3. pvcreate -ff –metadatacopies 1 –restorefile \/some\/file –uuid UUID \/dev\/device <\/li>\n
    4. vgcfgrestore -v -f \/some\/file volumeGroup <\/li>\n
    5. pvresize \/dev\/device <\/li>\n<\/ol>\n

      Notez que la commande vgcfgbackup pourrait \u00eatre remplac\u00e9e par la simple copie du fichier de configuration pr\u00e9sent dans \/etc\/lvm\/backup. Notez aussi que pour pouvoir stopper le groupe de volume (vgchange -an), il faut bien \u00e9videment avoir auparavant d\u00e9monter tous les syst\u00e8mes de fichiers, ou ce qui pourrait utiliser les volumes logiques d’une fa\u00e7on 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.<\/p>\n

      Cette op\u00e9ration \u00e0 parfaitement fonctionn\u00e9e et contrairement \u00e0 ce qui est indiqu\u00e9 dans la documentation elle me semble absolument sans risques (a condition que vous ne fassiez pas n’importe quoi bien sur..). <\/p>\n

      Comme d’habitude, je suis impressionn\u00e9 par ce formidable outil qu’est LVM. Comment faisait on avant ? <\/p>\n","protected":false},"excerpt":{"rendered":"

      Je vous rassure, quand je parle de \u00ab\u00a0frayeur\u00a0\u00bb, 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\u00e9tude… La situation \u00e9tait la suivante. Un serveur […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-189","post","type-post","status-publish","format-standard","hentry","category-geekitude"],"_links":{"self":[{"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/posts\/189","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/comments?post=189"}],"version-history":[{"count":0,"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/posts\/189\/revisions"}],"wp:attachment":[{"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/media?parent=189"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/categories?post=189"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hoper.dnsalias.net\/atdc\/index.php\/wp-json\/wp\/v2\/tags?post=189"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}