Forum Linux.général Help avec mdadm

Posté par mururoa69 le 03 mars 2008 à 13:19.

Étiquettes :

mar.

2008

Salut,

J'avais un beau raid 1 + 0 sur mon serveur debian etch mais au reboot bang, le raid ne remonte plus. Comme je ne suis pas un expert en raid soft linux je viens ici demander un peu d'aide.
Mon raid est constitué de 3 devices en raid1
md0
md1
md2
assemblés en raid 0
md4
A la création aucun souci le raid était opérationnel.
Au reboot j'ai un souci qui vient apparemment d'un mauvais uuid. Les 3 raid 1 sont bien actifs mais le raid 0 ne veut pas se former.



# cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md0 : active raid1 sda1[0] sdb1[1]

      35559744 blocks [2/2] [UU]



md1 : active raid1 sdc1[0] sdd1[1]

      17775808 blocks [2/2] [UU]



md4 : inactive md0[0] md1[1]

      53335424 blocks



md2 : active raid1 sde1[0] sdf1[1]

      35559744 blocks [2/2] [UU]



#  mdadm --assemble /dev/md4 /dev/md0 /dev/md1 /dev/md2

mdadm: superblock on /dev/md2 doesn't match others - assembly aborted



# mdadm --assemble --scan /dev/md4

mdadm: /dev/md4 assembled from 2 drives - not enough to start the array.



# cat /etc/mdadm/mdadm.conf

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=b569d5cf:78e814f6:750f0268:3080b0dc

   devices=/dev/sda1,/dev/sdb1

ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa524ad8:3dd85660:750f0268:3080b0dc

   devices=/dev/sdc1,/dev/sdd1

ARRAY /dev/md2 level=raid1 num-devices=2 UUID=67fecc8b:ff337754:750f0268:3080b0dc

   devices=/dev/sde1,/dev/sdf1

ARRAY /dev/md4 level=raid0 num-devices=3 UUID=f77dd017:20f9cbd5:750f0268:3080b0dc

   devices=/dev/md0,/dev/md1,/dev/md2



# mdadm --examine --scan --verbose

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=b569d5cf:78e814f6:3863c007:3efea49a

   devices=/dev/sdb1,/dev/sda1

ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa524ad8:3dd85660:3863c007:3efea49a

   devices=/dev/sdd1,/dev/sdc1

ARRAY /dev/md2 level=raid1 num-devices=2 UUID=67fecc8b:ff337754:3863c007:3efea49a

   devices=/dev/sdf1,/dev/sde1

ARRAY /dev/md4 level=raid0 num-devices=3 UUID=f77dd017:20f9cbd5:3863c007:3efea49a

   devices=/dev/md2

ARRAY /dev/md4 level=raid0 num-devices=3 UUID=f77dd017:20f9cbd5:750f0268:3080b0dc

   devices=/dev/md0,/dev/md1

On voit bien la différence d'uuid mais qu'est-ce que je peux faire pour forcer le raid à se reformer ?
Question subsidiaire : pourquoi ça a foiré au boot après un shutdown clean ?

# A tout hasard

Posté par Chris K. le 03 mars 2008 à 15:16. Évalué à 1.

Je vois que dans ton mdstat ton md4 viens avant ton md2, il ne serait pas déclaré avant dans ton raidtab ?

Ca expliquerai pourquoi il ne remonte pas, le md2 ne serait pas encore actif au moment ou il essayerai de demarrer le 4
- [^] # Re: A tout hasard
  
  Posté par Chris K. le 03 mars 2008 à 15:18. Évalué à 1.
  
  Rah réponse a moi même je cherchais un raidtab alors que c'est dans mdadm.conf maintenant et c'est dans le bon ordre...
  
  Je trouve quand même bizard qu'il ne te les mette pas dans l'ordre dans /proc/mdstat
  - [^] # Re: A tout hasard
    
    Posté par tguez le 03 mars 2008 à 17:40. Évalué à 1.
    
    Oui il y a des incohérences pour l'ordre des sorties de /proc/mdstat : md4 devrait être à la fin. Aussi entre /etc/mdadm/mdadm.conf et la sortie de mdadm --examine --scan --verbose : la description de /dev/md4 est contradictoire : 2 ou 3 composants ? /dev/md2 semble "oublié" au moins depuis le reboot.
# mdadm --create ...

Posté par tguez le 03 mars 2008 à 17:32. Évalué à 1.

Pour la reconstruction d'un RAID 1 (mirroring) détruit, j'ai eu des succès éphémères avec "mdadm --build" et définitifs avec "mdadm --create". Comme là il ne s'agissait pas de stripping, j'ai pu utiliser "missing" pour désigner un disque dur en rade... A toi de voir s'il faut que tu fasses un ou plusieurs "mdadm --create" ?

Dans ton cas, si tu n'as pas de sauvegarde, essaie sur une configuration de test d'abord. Sinon, peut-être se donner une possibilité de seconde chance en remontant que la moitié des RAID 1 ? Si j'étais assuré par une bonne sauvegarde vérifiée, je tenterai bien de suite de mémoire un "(à vérifier !!!!) # mdadm --create /dev/md4 --level=0 --nb-devices=3 /dev/md0 /dev/md1 /dev/md2 # (à vérifier !!!)". Où est passé ton /dev/md3 ? A quoi servait-il ?

Si tu n'as pas de sauvegarde, commence par en faire une, par copîes des disques, on trouve le 500Go à environ 100 euros, ça peut valoir la peine !!!

Je ne comprends pas pourquoi ton cas s'est produit, une mise à jour du noyau peut-être ? Un initrd ou un initramfs foireux ? Ou un bogue système, hélas.

Vérifie que tous les disques et les partitions sont bien visibles (fdisk -l). Peut-être y a-t-il un problème BIOS, carte mère ou disque dur. Faire quelques petits "dd if=/dev/partitions_ou_disques_durs of=/dev/null count=10", en remplaçant partitions_ou_disques_durs par chacun de tes disques et de tes partitions pour voir s'ils sont vraiment frais et dispo, un "dmesg" aussi pour chercher les erreurs... Enfin, une alimentation qui commence à lâcher peut faire des drôles de soucis au démarrage : plus tu actives les disques, plus la tension baisse, jusqu'à que tout flanche.

Certains cas de déconfigurations ne sont visibles qu'après reboot.
- [^] # Re: mdadm --create ...
  
  Posté par tguez le 03 mars 2008 à 17:53. Évalué à 1.
  
  Tu peux aussi essayer d'analyser l'état de tes disques avec "smartctl -A /dev/sdx" où x prend ses valeurs dans {a,b,c,d,e,f} chez toi.
# soluce

Posté par fcartegnie le 03 mars 2008 à 17:52. Évalué à 2.

mdadm --manage /dev/md4 --remove /dev/md2
mdadm --manage /dev/md4 --add /dev/md2

S'il en veut tjs pas, reset du md2:
mdadm --misc --zero-superblock /dev/md2
# Ce qui serait sympa...

Posté par tguez le 03 mars 2008 à 23:24. Évalué à 1.

...Ce serait de nous dire ce que ça a donné : quelles commandes tu as essayé, ce qui a marché, et si tu as une idée de la connerie à ne pas faire pour qu'on ne se retrouve pas dans la même mouize un jour !

A part ça, une dernière idée : le programme testdisk/photorec pour récupérer les données : c'est grand luxe et ça m'a déjà sauvé une fois mais hors système RAID.
- [^] # Re: Ce qui serait sympa...
  
  Posté par mururoa69 le 04 mars 2008 à 14:28. Évalué à 2.
  
  Salut,
  
  Bon a priori rien n'a marché en mode manage, ni le remove ni le fail, et donc j'ai été réduit à détruire le md4 avec :
  
  mdadm --misc --zero-superblock /dev/md4
  
  reconfigurer le paquet mdadm avec
  
  dpkg-reconfigure mdadm
  
  Ensuite j'ai abandonné l'idée de faire du raid 0 sur mes devices en raid 1 et donc j'ai juste rajouté les 3 raid 1 dans la configuration lvm.
  
  J'ai perdu juste 55 GB. Avis aux amateurs de raid soft ! Enfin perdu oui mais comme c'était juste un miroir debian j'ai rechargé ensuite les GB perdus sur les autres miroirs.
  J'ose espérer que de simples raid 1 seront moins sensibles que le raid 1 + 0.
  J'attends d'avoir des sauvegardes valides pour arracher des disques en cours de fonctionnement et voir comment ça se comporte en récupération.
- [^] # Re: Ce qui serait sympa...
  
  Posté par mururoa69 le 04 mars 2008 à 14:31. Évalué à 1.
  
  Et quand à la connerie ben je ne vois vraiment pas. Le serveur était en etch à jour (auto mise à jour hehe). L'arrêt à été propre. Probablement la mauvaise idée de faire du raid 0 sur des devices raid 1. C'est supporté à la création mais visiblement pas trop au reboot.
  - [^] # Re: Ce qui serait sympa...
    
    Posté par tguez le 04 mars 2008 à 15:10. Évalué à 1.
    
    Merci pour ton retour d'expérience !
    
    Et est-ce que tu as aussi essayé "mon" mdadm --create ... ?
    
    Parce-que moi il m'a déjà sauvé la mise une fois mais sur du mirroring, avec une ou plusieurs pannes matérielles en cours...
    
    Par contre, dans ma panne à moi, je n'ai pas tiré grand chose du "dpkg-reconfigure mdadm", il faut quand même que tout soit prêt avant l'exécution de ce truc, pour moi il ne fait qu'entériner dans l'initramfs la configuration que tu viens de définir à coup de mdadm --....
    
    De toutes façons tu prends un risque minimum avec le mirroring, les partitions restent accessibles individuellement, en spécifiant le type de filesystem sous-jacent, par exemple "mount -t ext3"
    
    J'ai vu, acheté mais pas lu (!) encore un article dans Linux Pratique de ce mois-ci je crois sur smartctl...
    - [^] # Re: Ce qui serait sympa...
      
      Posté par mururoa69 le 04 mars 2008 à 16:30. Évalué à 2.
      
      --create n'a pas marché car les devices étaient déjà dans une config. --force n'a rien changé.
      
      --build arrivait à construire qq chose mais ça ne résistait pas au reboot.
      
      Merci pour l'info sur les raid 1 qui sont toujours en ext3.
      Je fais des tests dès que j'ai une sauvegarde propre.
      - [^] # Re: Ce qui serait sympa...
        
        Posté par tguez le 04 mars 2008 à 16:56. Évalué à 1.
        
        Oui, pour le --build ça sent l'option qui est là pour une compatibilité ascendante (à confirmer !). J'ai eu le même phénomène avec --build : dans /proc/mdstat les raids 1 étaient alors marqués "non-persistants" et effectivement, ils ne résistaient pas au reboot... Pas pratique pour les montages boot et root ...
        Mais ça reste étonnant que tu ai pu faire un --build là où un --create était refusé ; je n'ai pas essayé l'option --force (trop peur de perdre définitivement les données du client !)
        J'ai aussi pensé faire un initramfs perso mais la maintenance pour les admin. suivants : pas simple, pas sympa.
        
        Pour les Raid 1 qui sont en ext3, ma config. était plus simple que la tienne : je n'ai pas de LVM, c'était par exemple /dev/md0 == /dev/sda1 et /dev/sdc1, et /dev/md0 formaté en ext3 (mkfs.ext3). Et le raid 0 m'inquiète...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.