Heu... J'aimerai savoir pourquoi 4 SSD flanchent d'un coup ?
Alors… Cet épisode a désormais une suite…
Le 14 décembre 2018, nous avons à nouveau perdu 4 SSD Samsung 850 Pro. Pour rappel, nous avons acheté 10 SSD en mai 2015 (en un seul coup, dans un même magasin, les numéros de série se suivent malgré quelques trous dans les séquences). Nous avons deux serveurs donc nous avons mis 5 SSD par serveur. Dans chaque serveur, 4 SSD sont actifs (RAID 5 logiciel Linux), et 1 SSD est inactif (hot spare).
Début juin 2017, nous avons perdu 4 SSD le même jour dans l'un des serveurs. En décembre 2018, nous avons perdu 4 SSD le même jour dans l'autre serveur. C'est étrange : les SSD ont été mis en production le même jour et sont censées avoir le même nombre d'écritures puisque nous sommes en RAID et que DRBD écrit les mêmes données sur chaque serveur. Sur le serveur tombé en panne en juin 2017, je constate une variation de 10 To entre les SSD membres d'une même grappe RAID et je ne l'explique pas. Dans les détails, l'attribut SMART « Total LBA written » indique respectivement 37 To, 41 To, 43 To et 50 To.
Que s'est-il passé lors de cette panne de décembre 2018 ?
smartctl
ni de mdadm
donc nous sommes en mesure de récolter que peu d'éléments, ce qui exclu le nombre de secteurs écrits…dd if=/dev/sdb of=/dev/null
sur l'un des SSD restants. Après 94 Go de lecture, dd affiche « i/o error » et le noyau journalise « mpt2sas reset port » puis « mpt2sas removing unresponding device » ;dd
similaire sur un des SSD survivants. 227 Go sont lus avant que le noyau journalise « critical error ». Il suffit de dd skip=
3 secteurs pour que la lecture reprenne et que tout le contenu (512 Go) soit lu (mais cela signifie que nous avons 3 secteurs endommagés…). On recommence… Toujours aucun problème pour lire le contenu, à l'exception des trois secteurs défectueux ;
Ce que l'on peut exposer :