Forum Linux.général Help avec mdadm

Posté par  .
Étiquettes :
0
3
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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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.