RAID 5, mdadm, problème pour mount AU SECOURS

Support Debian
Tags: #<Tag:0x00007f63f4b90398>
#21

J’ai retrouvé un vieux mdadm.conf

ARRAY /dev/md/0 level=raid5 num-devices=6 metadata=1.2 name=SERVERHOME:0 UUID=02ba9226:d61eebac:c412cd88:b751206b
   devices=/dev/sdg1,/dev/sdh1,/dev/sdi1,/dev/sdj1,/dev/sdf1,/dev/sde1
ARRAY /dev/md/1 level=raid1 num-devices=2 metadata=1.2 name=SERVERHOME:1 UUID=25576a1e:8b29c612:363ad2d1:7ad82d92
   devices=/dev/sdb1,/dev/sdd1
ARRAY /dev/md/0 level=raid5 num-devices=6 metadata=1.2 name=SERVERHOME:0 UUID=02ba9226:d61eebac:c412cd88:b751206b
   devices=/dev/sdg1,/dev/sdh1,/dev/sdi1,/dev/sdj1,/dev/sdf1,/dev/sde1
ARRAY /dev/md/1 level=raid1 num-devices=2 metadata=1.2 name=SERVERHOME:1 UUID=25576a1e:8b29c612:363ad2d1:7ad82d92
   devices=/dev/sdb1,/dev/sdd1

Crois-tu que je pourrais m’en servir pour enlever mes deux nouveaux disques et retrouver un RAID fonctionnel…???

#22

Désolé je ne connais foremost que de nom, je ne l’ai jamais utilisé.

L’ennui, c’est que le nommage des disques /dev/sd* n’est pas stable et peut varier d’un démarrage à l’autre, d’un branchement à l’autre, après l’ajout ou le retrait d’autres disques…
Ce qui fait foi, c’est le “rôle” du disque (un numéro) inscrit dans les méta-données de son superbloc RAID affichées par mdadm --examine /dev/sd*, visible dans /proc/mdadm ou dans les informations détaillées affichées par mdadm --detail /dev/md0.

Visiblement ton vieux mdadm.conf a été rempli (2 fois) par mdadm --examine --scan --verbose. Je ne sais pas si l’ordre dans lequel les membres sont listés a une signification, mais même si c’est le cas elle n’est valable qu’avec l’ordre de nommage des disques au moment de son exécution.

Par contre je pense que mentionner les membres des ensembles par leur nom de périphérique dans ce fichier est une mauvaise idée puisque ces noms sont instables.

Aussi, je croyais que tu avais créé (–create) le RAID avec 6 disques puis tu l’avais étendu (–grow) à 8 avec 2 disques supplémentaires ? Si tu l’as recréé avec --create avec 8 disques au lieu de l’étendre, c’est sûr les données sont perdues.

#23

Non, non j’ai bien étendu avec --grow. Est-il possible de faire l’inverse? De diminuer pour que je revienne à 6 disques…???
A l’origine, j’avais 4 disques, puis j’en ai rajouté 2 avec --grow et nickel, là j’ai fait la même chose mais ça n’a pas donné le résultat espéré…

#24

Salut,
Tu peux envisager de reconstruire le tableau avec le drapeau --assume-clean. Il me semble qu’un RAID 5 c’est trois disques.
Tant que tu n’as rien formaté, tu peux tenté de recréer un jeu de 3 disques.

mdadm --stop /dev/md0
mdadm --create --assume-clean --level=5 --raid-devices=3 /dev/md0 /dev/sd[ghi]1 --verbose

#25

Oui c’est possible mais je ne sais pas du tout quel sera le résultat. Rien ne dit que la disposition des données correspondra à celle d’avant l’ajout des deux derniers disques. Je n’ai jamais tenté ce genre de manipulation, donc à ce stade je ne peux plus beaucoup t’aider.

Oui, mais pour que le résultat soit cohérent il faut que la disposition recréée corresponde à l’originale.

Trois disque au minimum. Il peut y en avoir davantage.

#26

Exact, peut prendre n disque pour une capacité de n-1.

mdadm --stop /dev/md0
mdadm --create --assume-clean --level=5 --raid-devices=8 /dev/md0 /dev/sd[ghijfekl]1 --verbose

#27

Merci beaucoup en tous cas, j’essaie de vous tenir au courant de la suite.

Trop risqué car partout ils disent que ça peut abîmer les données et je veux vraiment essayer de les récupérer…

#28

J’ai un peu de nouveau, j’ai réussi à faire un fsck /dev/md0. Après un paquet de réparations, j’ai essayé de monter ma grappe et j’ai le même message que la dernière fois :

root@SERVERHOME:/# mount /dev/md0
mount : mauvais type de système de fichiers, option erronée, superbloc
        erroné sur /dev/md0, page de code ou aide manquante, ou autre erreur
       Dans quelques cas certaines informations sont utiles dans syslog — essayez
       « dmesg | tail » ou quelque chose du genre

root@SERVERHOME:/# dmesg | tail
[243450.932301]  disk 3, o:1, dev:sdj1
[243450.932303]  disk 4, o:1, dev:sdf1
[243450.932304]  disk 5, o:1, dev:sde1
[243450.932305]  disk 6, o:1, dev:sdk1
[243450.932306]  disk 7, o:1, dev:sdl1
[343977.691385] foremost[6333]: segfault at 1 ip b7671417 sp bfc2cd2c error 4 in libc-2.13.so[b7630000+161000]
[558296.577244] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 65408 failed (33025!=24)
[558296.577284] EXT4-fs (md0): group descriptors corrupted!
[559390.816876] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 65408 failed (33025!=24)
[559390.816918] EXT4-fs (md0): group descriptors corrupted!


root@SERVERHOME:/# dmesg
[243450.853956] md: md0: recovery done.
[243450.932292] RAID conf printout:
[243450.932296]  --- level:5 rd:8 wd:8
[243450.932298]  disk 0, o:1, dev:sdg1
[243450.932299]  disk 1, o:1, dev:sdh1
[243450.932300]  disk 2, o:1, dev:sdi1
[243450.932301]  disk 3, o:1, dev:sdj1
[243450.932303]  disk 4, o:1, dev:sdf1
[243450.932304]  disk 5, o:1, dev:sde1
[243450.932305]  disk 6, o:1, dev:sdk1
[243450.932306]  disk 7, o:1, dev:sdl1
[343977.691385] foremost[6333]: segfault at 1 ip b7671417 sp bfc2cd2c error 4 in libc-2.13.so[b7630000+161000]
[558296.577244] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 65408 failed (33025!=24)
[558296.577284] EXT4-fs (md0): group descriptors corrupted!
[559390.816876] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 65408 failed (33025!=24)
[559390.816918] EXT4-fs (md0): group descriptors corrupted!

Est-ce que ça vous dit quelque chose???

#29

Non, cela ne me dit rien. S’il reste des erreurs, il faut peut-être exécuter fsck à nouveau.

Ceci dit, tu as apparement assemblé les membres de l’ensemble RAID avec une disposition qui fait que le superbloc ext4 est à la bonne position (au début du volume), mais cela ne veut pas dire que le reste l’est. Donc même si tu réussis à remettre le système de fichiers dans un état cohérent, il ne contiendra peut-être que de la bouillie.

#30

Re bonsoir tout le monde. Je reviens vers vous pour la suite de mes aventures…
Je veux essayer de mettre un neuvième disque pour voir si je peut monter et avoir accès à mes fichiers qui sont toujours sur les disques mais je ne sais pas dans quel état…

J’utilise :

root@SERVERHOME:/# mdadm /dev/md0 --grow --backup-file=home/fichiers/Public/Save --raid-devices=9
mdadm: Need to backup 28672K of critical section..
mdadm: /dev/md0: cannot create backup file home/fichiers/Public/Save: File exists

Qu’est-ce que la critical section???
Merci

#31

Voir la description de la “section critique” dans la page de manuel de mdadm :

   When relocating the first few stripes on a RAID5 or RAID6,  it  is  not
   possible  to  keep  the  data  on disk completely consistent and crash-
   proof.  To provide the required safety, mdadm disables  writes  to  the
   array  while this "critical section" is reshaped, and takes a backup of
   the data that is in that section.  For grows, this backup may be stored
   in  any spare devices that the array has, however it can also be stored
   in a separate file specified with  the  --backup-file  option,  and  is
   required  to  be  specified  for shrinks, RAID level changes and layout
   changes.  If this option is used, and the system does crash during  the
   critical  period, the same file must be passed to --assemble to restore
   the backup and reassemble the array.  When shrinking rather than  grow‐
   ing  the array, the reshape is done from the end towards the beginning,
   so the "critical section" is at the end of the reshape.

L’erreur semble venir de ce que le fichier de backup spécifié existe déjà.

Mais je ne vois pas bien en quoi agrandir encore l’ensemble RAID va aider à retrouver les données. Au contraire.