Bonjour, je viens de me rendre compte que mon raid5 venait de passer en dégradé le 27/11 !
This is an automatically generated mail message from mdadm
running on raid6
A Fail event had been detected on md device /dev/md127.
It could be related to component device /dev/sdd1.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md127 : active raid5 sdf1[3] sdb1[1] sdd1[0](F)
1953260544 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
bitmap: 2/8 pages [8KB], 65536KB chunk
unused devices: <none>
root@raid:# mdadm --detail --verbose /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Fri Sep 29 06:44:43 2017
Raid Level : raid5
Array Size : 1953260544 (1862.77 GiB 2000.14 GB)
Used Dev Size : 976630272 (931.39 GiB 1000.07 GB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Dec 6 05:51:08 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : raid6:2 (local to host raid6)
UUID : f1a0ef99:ea007236:03204e21:ceca4abf
Events : 13858
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 17 1 active sync /dev/sdb1
3 8 81 2 active sync /dev/sdf1
Il me manque la partition sdd1, pourtant le disque est bien visible dans l’utilitaire de disque.
Le SMART est bon : c’est un disque que j’ai acheter reconditionner chez LDLC, il a 2 mois d’heure de fonctionnement.
Je ne sais pas pourquoi il ne veut pas faire parti du raid
J’ai lu qu’il ne faut pas faire n’importe quoi dans cette situation, pour éviter de supprimer les données.
J’ai essayé un
root@raid:# mdadm /dev/md127 –add /dev/sdd1
mdadm: An option must be given to set the mode before a second device
(–add) is listed
et la je reste bloqué ne voulant pas faire de conneries
Par contre la table de partition a t’elle déjà été importé sur le disque à ajouté au raid ?
De ce que je vois non, donc mdadm ne parviendra pas à reconstruire le raid si il n’a pas un emplacement précisé pour copier les données.
Attention au moment de la copie de la table de partition de pas se tromper de sens dans la copie
Donc c’est partie pour 270 minutes c’est plutôt rapide et je peut toujours accéder a mes donnée en même temps.
ce qui est bizarre c’est que j’ai crée le raid il y a quelques semaines et je n’ai pas changer de disque et il n’est pas hs donc pourquoi je dois recréer la somme de contrôle ?
Sans analyse plus approfondie je ne pourrais t’en dire plus, mais le premier retour que tu nous fourni montre la partition ssd1 en dehors du raid.
Pour qu’une partition soit retiré d’un raid il faut un événement majeur tel que le décès du disque ou tout du moins sa non réponse.
Au travail nous avons eu des cas assez atypique de disque sortie de raid matériel ou software, des nappes mal branché qui se déconnecte avec les vibration ou une manipulation du châssis du serveur.
Des contrôleur raid physiques qui dégage des disques suite à des retards de communication ou des incompatibilité de disques (ssd en l’occurrence).
Les causes peuvent être nombreuses à toi de faire un check approfondie des logs pour voir
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.
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
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.
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.
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 :
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.
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.
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.
« 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é)
C’est moche, dissymétrique, pas harmonieux.
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.
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.
)
