Mais où est /dev/md2 ?

Support Debian
#1

Bonjour,

J’utilise depuis trois mois maintenant trois disques durs partitionnés ainsi
/dev/sd[abc][123] en Linux Raid Autodetect

J’ai /dev/md0 en raid 1 avec /dev/sd[abc]1 pour la partition /boot

J’ai /dev/md1 en raid 1 avec /dev/sd[abc]2 pour le volume group racinevg

J’ai /dev/md2 en raid 5 avec /dev/sd[abc]3 pour le volume group datavg

Cet après-midi, grand mal m’a pris de vouloir agrandir la partition /dev/md2

Je reprend mes notes car je l’avais déjà fait auparavant :

  • Je retire le disque /dev/sda3 de ma partition /dev/md2 grace à un mdadm -f suivi d’un mdadm -r
  • Un coup de cfdisk pour supprimer puis recréer la partition /dev/sda3
  • Je remet le disque dans le raid grace à un mdadm --add
  • J’attend la fin de la reconstruction avec cat /proc/mdstat
  • Je réitère cet exploit avec les deux autres disques

Lorsque ce petit manège est fini, j’agrandi la partition /dev/md2 grace à un mdadm – grow

Je lance un pvresize pour que mon volume group datavg voit la nouvelle taille.

Et là, c’est le drame… la partition n’a pas changée de taille d’un seul pouce.

Je me dis que faire ça à chaud n’était peut-etre pas une bonne idée, je reboot donc ma machine.

Et là, second drame, ça ne boote plus !!!

Je me retrouve bloqué sur grub

Un petit root (hd0,0) puis setup(0,0) relance tout ça par contre, /dev/md2 a disparu.

Un cat /proc/mdstat me liste seulement les informations des md0 et md1.

Voici une liste des commandes que j’ai tapées et leurs résultats

mdadm --assemble /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3
mdadm: looking for devices for /dev/md2
mdadm: no recogniseable superblock on /dev/sda3
mdadm: /dev/sda3 has no superbloc - assembly aborted

mdadm --zero-superblock /dev/sda3
mdadm: Unrecognised ld component device - /dev/sda3

mdadm --create /dev/md2 --level=5 --raid-devices=3 /dev/sda3 /dev/sdb3 /dev/sdc3
mdadm: super1.x cannot open /dev/sdc3: Device or ressource busy
mdadm: /dev/sdc3 is not suitable for this array
mdadm: create aborted

De quelles informations supplémentaires auriez-vous besoin pour me donner un coup de main avant que ma copine découvre que j’ai lamentablement perdu toutes nos photos prises depuis 5 ans :blush:

Merci d’avance

uname -a

Linux Athena 2.6.26-2-amd64 #1 SMP Thu Sep 16 15:56:38 UTC 2010 x86_64 GNU/Linux

mdadm --version

mdadm - v3.1.4 - 31st August 2010

#2

Normal.

Normal encore.
J’explique l’enchaînement infernal (je l’avais déjà fait dans un autre fil mais j’ai la flemme de chercher).

  1. Les volumes RAID auto-detect ont des superblocs au format 0.9 situés en fin de partitions.

  2. Quand on modifie la table de partition d’un disque dont au moins une partition est utilisée (système de fichier monté, volume RAID ou LVM actif, swap actif…), par exemple pour agrandir une partition existante, le noyau ne recharge pas la table de partition. Donc pour le noyau les partitions du disque n’ont pas changé. Le changement ne sera effectif qu’au prochain démarrage, ou quand on forcera le noyau à recharger la table de partition alors qu’aucune partition n’est utilisée.

  3. Quand tu réintègres la partition RAID (agrandie sur le disque, mais pas pour le noyau) dans l’ensemble RAID, elle est recréée avec le superbloc au même endroit qu’auparavant, c’est-à-dire à la “fin” correspondant à l’ancienne taille. Autant dire qu’il ne s’est rien passé.

  4. Les tailles des partitions RAID n’ayant pas changé pour le noyau, fort logiquement la taille de l’ensemble RAID ne change pas avec mdadm --grow.

  5. Au reboot, le noyau prend en compte les nouvelles tailles des partitions RAID. Mais voilà, les superblocs n’ont pas changé de position physique et se trouvent maintenant noyés quelque part au milieu des partitions RAID et non plus à la fin. Par conséquent la détection de l’ensemble RAID ne peut avoir lieu.

C’est un volume RAID 5 en bandes, donc il est bien plus difficile de récupérer les données qu’avec du RAID 1 en miroir. L’idéal serait de réduire les partitions à leur taille initiale exacte puis redémarrer. Si tu ne la retrouves pas, il va falloir utiliser un outil capable d’identifier un superbloc RAID (peut-être testdisk), mais je n’ai jamais essayé.

Ce qu’il aurait fallu faire pour agrandir le volume RAID sans rebooter, c’est :

  1. Sortir toutes les partitions RAID d’un disque de leurs ensembles respectifs, afin qu’aucune partition du disque ne soit plus utilisée.
  2. Agrandir la partition, et cette fois la nouvelle taille sera prise en compte immédiatement par le noyau.
  3. Réintégrer toutes les partitions du disque dans leurs ensembles RAID respectifs. Cette fois le superbloc de la partition agrandie sera positionné à la nouvelle fin de celle-ci.
  4. Recommencer avec les autres disques.
  5. Agrandir l’ensemble RAID avec mdadm --grow qui va prendre en compte la nouvelle taille des partitions RAID.

Je ne raconte pas le temps que ça va prendre car chaque réintégration va provoquer une reconstruction, et les risques d’erreur de manipulation (si on oublie de réintégrer une partition, paf l’ensemble quand on en retire une autre). Bref, à éviter.

Ou bien, plus simple nécessitant moins de reconstructions mais autant de reboots que de disques :

  1. Agrandir une partition. Optionnellement, la sortir de son ensemble RAID.
  2. Rebooter pour que la nouvelle taille soit prise en compte.
  3. Réintégrer la partition RAID dans son ensemble.
  4. Recommencer avec les autres partitions de l’ensemble.
  5. Agrandir l’ensemble RAID.

Ça reste laborieux car il faut rebooter pour chaque partition agrandie. Ma conclusion est que les partitions RAID ne sont pas faites pour être agrandies.

Une meilleure solution AMA, puisque tu as eu la bonne idée mettre du LVM sur tes ensembles RAID, c’est de créer un nouvel ensemble RAID, un nouveau PV LVM dessus, et d’ajouter celui-ci au VG à agrandir.

Note : Par contre, je n’explique pas le blocage de grub.

#3

ok, mon erreur a été de n’enlever du raid que la partition que je voulais agrandir et non l’ensemble des partitions du disque.

Je tente de remettre les partitions à leur taille originelles

…

Tu es mon idole, le serveur a redémarré, les données sont retrouvées.
Je retente d’agrandir tout ça en sortant cette fois l’ensemble des partitions des disques puis en redémarrant systématiquement à chaque manipulation histoire d’écarter le plus tot possible une éventuelle fausse manipulation.

J’ai voulu aller trop vite et j’avais même pas pris la peine de faire un cat /proc/partitions qui m’aurait certainement montré que la nouvelle taille de mes partitions n’étaient pas prises en compte.

Merci encore !!!

Je te rejoins dans ta conclusion. Un ensemble RAID ne devrait être modifié que si on touches physiquement aux disques durs (ajout/suppression). Ma manip d’hier était justement d’étendre mon RAID 5 à l’ensemble de l’espace libre de mes disques, ce que je n’avais pas fait à la création. Erreur que je ne referai plus, LVM est là pour allouer la place au bon endroit.

#4

C’est une façon de voir. Une autre façon de voir est que ton erreur a été de ne pas exploiter les fonctionnalités de LVM.

Je reviens à la charge : AMA il aurait été beaucoup plus simple et sûr de créer un nouvel ensemble RAID 5 dans l’espace disque libre, d’y créer un nouveau PV LVM et de l’ajouter au VG existant, plutôt que d’agrandir les partitions RAID, puis l’ensemble RAID, puis le PV et le VG. LVM est conçu pour dissocier l’organisation logique de l’organisation physique, il faut en profiter. En plus ça évite les redémarrages et les longues reconstructions des partitions RAID pendant lesquelles l’ensemble RAID 5 se retrouve sur deux pattes donc sans redondance, à la merci du moindre problème.

PS : si tes données sont importantes, pense aussi à faire une sauvegarde séparée. Le RAID n’est pas une sauvegarde.