RAID5 : remplacement de disque impossible

Support Debian
Tags: #<Tag:0x00007f509ff65f80>
#1

Bonjour les gens !
Oh que ça a changé ici, ça faisait longtemps que j’étais pas venu.
Alors voilà, après 6 heures de recherches et essais, je viens faire appel aux brutes du stockage, et surtout du RAID soft.

Mon problème :
J’avais un RAID5 (mdadm) avec 5 disques.
Tous les disques étant sains, je me suis lancé dans un agrandissement à 7 disques avec un commande du genre :
mdadm --grow /dev/md127 -n 7

Pas de soucis, cela a bien commencé à ajouter les disques. Ce n’est pas la première fois que je fais l’opération. Mais à 70% de restructuration j’ai un disque du RAID (un qui était déjà là avant) qui a lâché. Imposible de récupérer son état smart tellement il a lâché…

En regardant un peu /proc/mdstat j’ai constaté :

  • que le raid est bien défini maintenant sur 7 disques
  • que le sdg était défectueux (F)

sauf que la restructuration s’est arrêtée…

Après avoir consulté des collègues pour savoir ce qu’ils en pensaient, j’ai déclaré le sdg fautif et je l’ai supprimé de l’array.

J’ai ensuite viré le HDD HS et remplacé par un neuf (en hot plug vu que ma carte contrôleur le gère).

J’ai partitionné le neuf mais lorsque j’ai voulu l’ajouter, il me disait “invalid argument”. J’ai bien évidemment vérifié ma commande et elle est bonne :
mdadm --manage /dev/md127 --add /dev/sdg1

En regardant avec mdadm --detail je vois que l’ancien disque (le 4ème disque de l’array) apparait maintenant en removed… Et impossible d’ajouter le nouveau.

En désespoir de cause j’ai tenté un reboot, et maintenant j’ai bien le sdg1 qui fait partie de l’array mais en disque de spare, et je vois toujours un disque “removed”

J’en suis là et je ne sais pas trop quoi tenter. J’ai bien essayé des mdadm --assemble etc mais rien ne m’aide. Je vois toujours un disque removed et mon nouveau disque en “spare”

Si une âme charitable veut bien m’aider afin que je ne passe pas un sale réveillon demain soir…

Merci d’avance.

#2

Première question, est-ce que l’ensemble RAID s’assemble et s’active automatiquement au démarrage ?
Si oui, commencer par faire une sauvegarde de ce qui a besoin d’être sauvegardé.
As-tu tenté de refaire un --grow, éventuellement avec --continue (sans garantie) ?

(Personnellement, avec 7 disques, je commencerais à envisager du RAID 6 au lieu du RAID 5.)

#3

Salut Pascal !
Tu m’avais sauvé il y a longtemps alors, j’espère que tu pourras le faire encore ici :smiley:

Au boot il me dit qu’il peut pas assembler le RAID.

Ensuite voila quelques infos en plus :

mdadm -D /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
Raid Devices : 7
Total Devices : 6
Persistence : Superblock is persistent

    Update Time : Sat Dec 31 00:38:39 2016
          State : active, degraded, Not Started 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

  Delta Devices : 2, (5->7)

           Name : Srv01:FPS  (local to host Srv01)
           UUID : e9d00ef5:c541a6b9:77b27878:d64af109
         Events : 17321

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      active sync   /dev/sdd1
       5       8      113        3      active sync   /dev/sdh1
       4       0        0        4      removed
       7       8       81        5      active sync   /dev/sdf1
       6       8       65        6      active sync   /dev/sde1

cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : inactive sdb1[0] sde1[6] sdf1[7] sdh1[5] sdd1[3] sdc1[1]
11721074533 blocks super 1.2

unused devices: <none>

Et quand je tente d’ajouter mon disque neuf :
mdadm --manage /dev/md127 --add /dev/sdg1
mdadm: add new device failed for /dev/sdg1 as 8: Invalid argument

J’ai retesté un --grow (sans --continue) mais il me dit que j’ai rien changé donc que c’est pas possible…

Ba du coup je me dit sinon avec 7 disque pourquoi pas faire 6 + 1 spare. (j’ai lu que le RAID 6 avant de mauvaises perfs…)

#4

Autre commande qui peut peut être en dire plus à certains :

mdadm --examine /dev/sd[bcdefgh]1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x4
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 7

 Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
     Array Size : 11721071616 (11178.09 GiB 12002.38 GB)
  Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : c811ce92:5ac76dbe:371ef366:f1c55a8f

  Reshape pos'n : 8255284224 (7872.85 GiB 8453.41 GB)
  Delta Devices : 2 (5->7)

    Update Time : Sat Dec 31 00:38:39 2016
       Checksum : f485d60b - correct
         Events : 17321

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAA.AA ('A' == active, '.' == missing)
/dev/sdc1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
           Name : Srv01:FPS  (local to host Srv01)
  Creation Time : Mon Sep 24 18:26:31 2012
     Raid Level : raid5
   Raid Devices : 7

 Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
     Array Size : 11721071616 (11178.09 GiB 12002.38 GB)
  Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : afbe1115:37b89909:67bd9aac:aad763cf

  Reshape pos'n : 8255284224 (7872.85 GiB 8453.41 GB)
  Delta Devices : 2 (5->7)

    Update Time : Sat Dec 31 00:38:39 2016
       Checksum : 47a61b51 - correct
         Events : 17321

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAAA.AA ('A' == active, '.' == missing)
/dev/sdd1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
           Name : Srv01:FPS  (local to host Srv01)
  Creation Time : Mon Sep 24 18:26:31 2012
     Raid Level : raid5
   Raid Devices : 7

 Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
     Array Size : 11721071616 (11178.09 GiB 12002.38 GB)
  Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : f6fb0dec:ca8a7af1:6ce26ab6:141b4132

  Reshape pos'n : 8255284224 (7872.85 GiB 8453.41 GB)
  Delta Devices : 2 (5->7)

    Update Time : Sat Dec 31 00:38:39 2016
       Checksum : 733092f5 - correct
         Events : 17321

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAA.AA ('A' == active, '.' == missing)
/dev/sde1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
           Name : Srv01:FPS  (local to host Srv01)
  Creation Time : Mon Sep 24 18:26:31 2012
     Raid Level : raid5
   Raid Devices : 7

 Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
     Array Size : 11721071616 (11178.09 GiB 12002.38 GB)
  Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : 27722158:f54034c0:d2543dc0:780ac3ab

  Reshape pos'n : 8255284224 (7872.85 GiB 8453.41 GB)
  Delta Devices : 2 (5->7)

    Update Time : Sat Dec 31 00:38:39 2016
       Checksum : 31522b2e - correct
         Events : 17321

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 6
   Array State : AAAA.AA ('A' == active, '.' == missing)
/dev/sdf1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
           Name : Srv01:FPS  (local to host Srv01)
  Creation Time : Mon Sep 24 18:26:31 2012
     Raid Level : raid5
   Raid Devices : 7

 Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
     Array Size : 11721071616 (11178.09 GiB 12002.38 GB)
  Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : fee2118e:38f29a49:1afe20b2:e9fa0041

  Reshape pos'n : 8255284224 (7872.85 GiB 8453.41 GB)
  Delta Devices : 2 (5->7)

    Update Time : Sat Dec 31 00:38:39 2016
       Checksum : 77cae701 - correct
         Events : 17321

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 5
   Array State : AAAA.AA ('A' == active, '.' == missing)
/dev/sdg1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
           Name : Srv01:FPS  (local to host Srv01)
  Creation Time : Mon Sep 24 18:26:31 2012
     Raid Level : raid5
   Raid Devices : 7

 Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
     Array Size : 11721071616 (11178.09 GiB 12002.38 GB)
  Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : d7b5391e:fe0ffb08:e8c9c501:21ca5ee1

  Reshape pos'n : 8255284224 (7872.85 GiB 8453.41 GB)
  Delta Devices : 2 (5->7)

    Update Time : Sat Dec 31 00:38:39 2016
       Checksum : b7552efe - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : spare
   Array State : AAAA.AA ('A' == active, '.' == missing)
/dev/sdh1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
           Name : Srv01:FPS  (local to host Srv01)
  Creation Time : Mon Sep 24 18:26:31 2012
     Raid Level : raid5
   Raid Devices : 7

 Avail Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
     Array Size : 11721071616 (11178.09 GiB 12002.38 GB)
    Data Offset : 1712 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : 1ef2defd:ff5897e1:87328aa7:7d4a733d

  Reshape pos'n : 8255284224 (7872.85 GiB 8453.41 GB)
  Delta Devices : 2 (5->7)

    Update Time : Sat Dec 31 00:38:39 2016
       Checksum : 716fd0f9 - correct
         Events : 17321

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAA.AA ('A' == active, '.' == missing)
#5

Le --grow --continue me retourne une erreur

mdadm --grow --continue /dev/md127
Erreur de segmentation

#6

Quelle version de Debian et de noyau ?

J’ai fait une simulation pour voir, et si je mets un membre en fail et le retire pendant le reshape, le reshape continue quand même. Puis si j’ajoute un spare, il est utilisé après la fin du reshape pour lancer la reconstruction du membre manquant.

D’autre part, si j’arrête l’ensemble avant la fin du reshape, l’ensemble est bien actif à l’assemblage suivant, en mode auto-read-only tant qu’on n’écrit pas dedans.

Je n’ai donc pas réussi à reproduire ta situation. Tu pourrais tenter un --run pour forcer l’ensemble à démarrer, mais sans garantie. En tout cas je ne pense pas qu’on puisse faire quelque chose tant qu’il n’est pas démarré.

#7

Noyau : 3.2.0.4
Debian version 7.11

J’arrive à assembler le RAID, mais il est en dégradé sur 6 disques, et il met le dernier en spare tout seul.
Aucune restructuration ne se fait, et il ne remplace pas non plus le disque “removed” par le disque de spare…

mdadm --detail /dev/md127

/dev/md127:
        Version : 1.2
  Creation Time : Mon Sep 24 18:26:31 2012
     Raid Level : raid5
     Array Size : 7814047744 (7452.06 GiB 8001.58 GB)
  Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
   Raid Devices : 7
  Total Devices : 7
    Persistence : Superblock is persistent

    Update Time : Sat Dec 31 15:31:16 2016
          State : clean, degraded 
 Active Devices : 6
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 512K

  Delta Devices : 2, (5->7)

           Name : Srv01:FPS  (local to host Srv01)
           UUID : e9d00ef5:c541a6b9:77b27878:d64af109
         Events : 17337

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      active sync   /dev/sdd1
       5       8      113        3      active sync   /dev/sdh1
       4       0        0        4      removed
       7       8       81        5      active sync   /dev/sdf1
       6       8       65        6      active sync   /dev/sde1

       8       8       97        -      spare   /dev/sdg1
#8

est-ce possible ? mais sans doute dangereux ? de repasser le raid en 6 devices pour qu’il enlève le removed… et ensuite le repasser à 7 (ou rester à 6 + 1 spare)

#9

Je l’ignore, je ne l’ai jamais tenté.

Maintenant que l’ensemble semble démarré, que contient /proc/mdstat ?
Si l’ensemble est opérationnel, tu peux en profiter pour sauvegarder les données importantes qu’il contient. Ainsi au pire tu pourras le recréer.

Dans mes tests, la reconstruction (resync) du spare n’a commencé qu’après la fin de la restructuration (reshape), qui n’est pas terminée ici (sa taille apparente est toujours 8 To).

#10

Voilà !

#cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdb1[0] sdg18 sde1[6] sdf1[7] sdh1[5] sdd1[3] sdc1[1]
7814047744 blocks super 1.2 level 5, 512k chunk, algorithm 2 [7/6] [UUUU_UU]

unused devices: <none>
#11

J’ai finalement plus ou moins réussi à reproduire cet état problématique où l’ensemble est actif mais le reshape ne reprend pas. J’ai essayé des choses comme

echo active > /sys/block/md0/md/array_state
echo reshape > /sys/block/md0/md/sync_action
echo resync > /sys/block/md0/md/sync_action

Dans les logs du noyau, lors de ces commandes, je voyais ceci :

md/raid:md0: reshape: not enough stripes.  Needed 512

Une recherche sur le web me conduit à

echo 600 > /sys/block/md0/md/stripe_cache_size

et le reshape reprend, puis la reconstruction du spare.
Il faudra adapter le nom md0 et peut-être la valeur à ta situation.

#12

Pascal, tu es un Dieu du RAID.
J’ai suivi tes lignes de commandes, effectivement le reshape a repris.
…
Mais c’était trop beau pour que ça fonctionne, alors au bout de 5 minutes même pas, j’ai eu des messages d’erreurs du Kernel. J’ai regardé dans le syslog : un autre HDD a lâché… (le même modèle de chez Seagate que le premier…)

Du coup là j’ai un RAID 5 avec deux disques en moins et pas terminé de reconstruire en plus…

Je vais sans doute tenter de faire un dd bit à bit du HDD qui a lâché en dernier, mais là je pense que c’est mort, je peux bien m’asseoir sur mes données :cry:

#13

Au reboot, le second “disque problématique” semble fonctionner normalement.
J’ai relancé le reshape il a fait 0,1% puis ça a refait la même chose.
Penses tu que je dois économiser le disque et essayer un DD ?
Ou retenter encore et encore le reshape ?
Ou faire un fsck ?

#14

Quel type d’erreur exactement ?
J’ai eu un disque dur en RAID aussi (me souviens plus la marque, mais pas un Seagate) qui démarrait bien puis s’arrêtait de fonctionner subitement jusqu’à ce qu’on le mettre hors tension puis sous tension à nouveau. Aucun défaut signalé par smartctl. Je l’ai remplacé.

C’est quand même étonnant que ça arrive sur deux disques au même moment, ou alors c’est une mauvaise série. Il pourrait aussi y avoir un autre facteur commun : température excessive (disque collés les uns aux autres sans ventilation suffisante), alimentation faiblissante, carte mère, contrôleur SATA…

En tout cas je renouvelle ma recommandation de sauvegarder toutes les données importantes si c’est encore possible car l’ensemble RAID n’a plus de redondance depuis la défaillance du premier disque. Et d’éviter toute opération d’écriture sur les disques en RAID tant que ce n’est pas fait (donc pas de reshape ni de fsck). Eventuellement une copie bit à bit avec dd en vue de son remplacement.

#15

Les 2 seagate ont été achetés ensemble je pense… Donc ils ont subi la même “usure”…
Malheureusement là, je n’accède pas aux données, je pense qu’il faut finir le reshape.
Pour les erreurs je ne sais plus trop j’ai pas noté. mais en gros juste après l’erreur, le HDD passe en (F) dans /proc/mdstat
Obligé de rebooter pour qu’il redevienne normal.

Quand il est en (F), je n’accès plus aux données smart
J’aimerai juste arriver à remonter le RAID juste le temps de récup les données dont je n’ai pas de backup (je récup des HDD pour ça…)

Mais c’est pas gagné. Avec les HDD que je vais récup j’aimerai faire du DD, mais ensuite je n’ai plus de disques pour sauver les données… sacré problématique.

Je pense que si le reshape fini, je serait en mode dégradé mais je pourrais surement monter le RAID pour récup les data.

Est-ce que je tente de le monter pendant qu’il fait son reshape ? ou je le laisse faire ? là j’ai relancé le reshape depuis quelques minutes et j’ai pas eu d’erreur pour le moment… Je suis passé de 70,5 à 72,2%

#16

Ah oui et pour répondre a tes questions Pascal :

  • la tour est bien ventilée (watercooling pour le prosss + 3 ventilos de boitier 12cm)
  • Pas de chauffe et je nettoie régulièrement la tour pour la poussière.
  • L’alim est assez récente (l’ancienne avait lâché). C’est une LEPA 80Plus (il me semble que ça appartient à un groupe du genre thermaltake ou truc comme ça…)
  • tous les disques ne sont pas sur le même controleur : il y a celui de la CM et celui de la carte additionnelle achetée en 2015. Il se peut que la CM soit fatiguée ou que l’alim faiblisse effectivement… mais c’est bizarre que ce soit les 2 vieux seagate qui rendent l’âme ensembles…
#17

Salut Pascal,
A coup de mdadm --stop et mdadm --assemble, j’ai réussi avec ta commande “echo active…” a terminer le reshape. Cela a ensuite enchaîné avec le recovery sur le disque de spare. Mais la, le recovery bloque a 70,4%. n’aurais tu pas une astuce pour qu’il soit moins regardant sur l’état des disques et pour forcer la fin du recovery ? je suis si proche du but…