Raid 5 dégradé !

Support Debian
#6

oh que oui mais si tu avait intervertis plusieurs disques ton raid ne serait pas remonté.

Si tu as par contre simplement rebrancher sur une autre prise ce disque alors là oui c’est largement suffisant pour le rendre étranger à la configuration du raid et le sortir de celui-ci.

Généralement je travaille sur des châssis rack donc à moins de se tromper de panier … et le peu de châssis plus traditionnel nous ne faisons que du raid 1 ou 0 donc ça limite les risques de se tromper dans un raid.

Lors du démontage d’un serveur pour ne pas risquer de se tromper il est sans doute avisé d’étiqueté les disques, lors du branchement il y aura moins de souci ;), et idem pur les switch/routeur.

#7

après c’est pas vraiment un serveur c’est juste un cm avec quelques disque , mais oui c’est bizarre , normalement c’est identifié par un uuid et je crois que c’est le cas

#8

Non, non !
Il fallait mettre la partition sdd1 et non le disque entier sdd. On n’utilise pas un disque entier partitionné comme membre d’un ensemble RAID.
Maintenant le disque entier contient à la fois un superbloc RAID et une table de partition définissant une partition contenant aussi un superbloc RAID (différent mais du même ensemble RAID). Risque de confusion maximum. Et en prime si la table de partition du disque est au format GPT, le nouveau superbloc a été placé en plein milieu de celle-ci et en a écrasé une partie.

Faux et faux (sauf si on l’a fait à chaud évidemment). La détection et l’assemblage des membres d’ensemble RAID se base sur des UUID, donc peu importe leur position physique.

#9

Salut pascal :wink:
Donc c’est quoi le problème maintenant ?

fdisk -l

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disque /dev/sdd : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5D7A3720-45CD-4E9B-910E-97D1F7C6C55F

Périphérique Start        Fin   Secteurs   Size Type
/dev/sdd1     2048 1953525134 1953523087 931,5G RAID Linux

Que dois-je faire ???

#10

un simple mdadm --manage --add /dev/md127 dev/sdd1
ou reformater le disque et le ré ajouter ?

Sinon la recréation (enfin l’ajout du disque) n’a pris que 3-4h pour 1To je pensais que ça prendrait plus de temps que ça.

#11

Autant pour moi pour l’oubli de la partition, mais que je rassure Pascal je ne proposais pas à ce moment là d’ajouter le disque entier mais bien la partition, sans doute un oubli de ma part ou une mauvaise frappe sur le clavier.

J’ai plus l’habitude de travailler avec le serveur en marche qu’a l’arrêt.

#12

Le problème, c’est ce que j’ai expliqué et dont tu vois une conséquence : table de partition GPT primaire corrompue par l’écriture du superbloc RAID en plein milieu de celle-ci.

Tu as trois options :

  1. Ne rien faire. Ça peut continuer à marcher. Ou pas, et un jour le système peut décider que la table de partition GPT prend le pas sur le superbloc RAID et empêcher l’assemblage de ce disque.

  2. Effacer les signatures de table de partition DOS et GPT du disque sdd (pas la table entière, sinon tu effaces aussi le superbloc RAID qui occupe le même emplacement). Le disque sdd apparaîtra alors comme non partitionné, et utilisé en entier comme membre RAID. Avantage : rapidité. Inconvénient : la structure de sdd sera différente de celle des deux autres disques.

  3. Retirer le disque sdd de l’ensemble RAID, effacer le superbloc RAID de sdd, restaurer la table de partition primaire de sdd à partir de la table de partition de secours, et ajouter la partition sdd1 à l’ensemble RAID, ce qui relancera une reconstruction complète. Avantage : sdd aura la même structure d’origine que les deux autres disques. Inconvénient : long (reconstruction), et l’ensemble RAID reste dégradé pendant la reconstruction donc s’il perd encore un disque il est mort.

#13

Je vois, la seconde option me tente plus, tu a un lien qui explique cette manip ? et quel est inconvénient d’avoir une structure différente ?

#14

“J’étais sûr que vous diriez ça !” (saurez-vous retrouver de quel film cette réplique est tirée ?)
Pour effacer les deux premiers secteurs du disque contenant le MBR et la signature GPT :

dd if=/dev/zero of=/dev/sdd bs=512 count=2

Attention : bien s’assurer avant que le disque à traiter est bien vu comme sdd. Cela peut changer d’un démarrage à l’autre.

(il y a un autre moyen plus “soft” avec wipefs, mais c’est plus compliqué)

  1. C’est moche, dissymétrique, pas harmonieux.

  2. Un disque sans table de partition, je trouve que c’est risqué même si une table de partition n’est pas obligatoire (du moins pour Linux). On finit par se demander ce qu’il contient et on peut croire à tort qu’ils ne contient rien puisqu’il n’y a aucune partition. Certains logiciels de gestion des disques “bien intentionnés” pourraient même proposer lourdement d’y créer une table de partition, écrasant une partie de son contenu.
    Inversement, quand un disque contient une partition de type Linux RAID, on sait tout de suite qu’il est membre d’un ensemble RAID logiciel.

#15

Judge Dredd ? (meme si je ne l’ai pas vu :stuck_out_tongue: )

Bon je ne sais pas quoi prendre finalement entre la seconde et troisième: je me tâte :smiley:

#16

Bravo !

Techniquement, l’option 2 est parfaitement valide (du moins avec Linux). Ses inconvénients sont dus au facteur humain.
Mais même si une commande comme blkid peut détecter le type de contenu d’un disque partitionné ou non, l’expérience montre qu’on utilise plus volontiers un outil comme fdisk pour examiner un disque.

#17

Bon j’ai fait un dd if=/dev/zero of=/dev/sdd bs=512 count=2 du coup après il se passe quoi ? tout rentre dans l’ordre comme par magie ? :smiley:

Sinon le mdstat renvoie bien les 3 UUU

#18

Après tu peux vérifier que les signatures de tables de partitions ont disparu mais pas le superbloc RAID.

wipefs /dev/sdd
fdisk -l /dev/sdd
mdadm --examine /dev/sdd
#19

Yes ! merci Pascal et Clochette pour votre aide !

Disque /dev/sdd : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
# mdadm --examine /dev/sdd
/dev/sdd:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 
           Name : raid6:2  (local to host raid6)
  Creation Time : Fri Sep 29 06:44:43 2017
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
     Array Size : 1953260544 (1862.77 GiB 2000.14 GB)
  Used Dev Size : 1953260544 (931.39 GiB 1000.07 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262056 sectors, after=2480 sectors
          State : clean
    Device UUID : 
Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Dec  8 02:54:40 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : ac8cb011 - correct
         Events : 15974

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
#20

Bon j’ai peut être parler trop vite …

# mdadm --examine /dev/sdd
mdadm: No md superblock detected on /dev/sdd.

j’ai encore perdu le même disque !

#21

Qu’est-ce qui s’est passé depuis la dernière fois pour en arriver là ?
Les disques n’auraient pas changé de noms ?
Que disent

cat /proc/mdstat
mdadm --examine --verbose --scan
#22

j’ai reboot entre temps, d’ailleur je ne sais pas si c’est la cause d’une utilisation de ram mais je suis souvent a 100% de ram(4g) use et 10-40% de swap(5g).
C’est un logiciel(SIA host) qui pompe la ram mais il utilise le raid comme espace de stockage

Les disque ont bien les même noms.

cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md127 : active raid5 sdf1[3] sdb1[1] sdd[4](F)
      1953260544 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
      bitmap: 5/8 pages [20KB], 65536KB chunk

unused devices: <none>

donc la même chose que la dernière fois

mdadm --examine --verbose --scan
ARRAY /dev/md/2  level=raid5 metadata=1.2 num-devices=3 UUID=f1a0ef99:ea007236:03204e21:ceca4abf name=raid6:2
   devices=/dev/sdf1,/dev/sdb1
#23

Je n’ai pas d’explication. Un superbloc RAID n’est pas censé disparaître comme ça. Le disque est peut-être défectueux ? Tu l’as vérifié avec smartctl du paquet smartmontools ?

Tu peux en profiter pour recréer une table de partition et une partition RAID, et resynchroniser le RAID sur la partition comme initialement et comme sur les deux autres disques. Mais si quelque chose efface le superbloc de façon récurrente, cela ne règlera pas le problème.

PS : J’ai modifié ton message pour mettre le contenu de /proc/mdstat en format texte préformaté, sinon la mise le forum interprète son contenu comme une mise en forme et affiche sdd[4](F)comme sdd4.
(Si quelqu’un a une explication je prends)

#25

J’ai jeter un coup d’œil de SMART via l’utilitaire d’Ubuntu : tout est bon (si tu a une commande particulière avec smartctl en tête?).

Comme dis plus haut c’est un disque dur reconditionné, quand je l’ai eu il avait très peu servi, 2 mois sans problèmes, c’est possible que SMART ne détecte pas la panne ?
Je vais effectivement reformater le disque et le ré-ajouter, si le problème se reproduit ça veut dire que c’est uniquement matériel ? Si c’est le cas comment je peut prouver la panne auprès du sav de ldlc ?

#26 
smartctl -a /dev/sdd

Il est toujours possible que SMART ne détecte pas une panne, surtout si elle ne provoque pas d’erreurs visibles. Mais les codes correcteurs intégrés aux données enregistrés devraient permettre de détecter une altération de celles-ci. Des disques avec des erreurs et des secteurs illisibles, j’en ai vu un tas, mais un disque qui perd spontanément ses données sans erreur, jamais.

Est-ce que cela arrive toujours suite à un redémarrage, ou en cours de fonctionnement ?