Mon histoire commence tout simplement. J'ai un serveur léger, exécutant Arch Linux, qui stocke la plupart de ses données sur un RAID-1 composé de deux disques SATA. Il fonctionnait sans aucun problème pendant environ 4 mois. Puis, tout à coup, j'ai commencé à obtenir des erreurs de lecture sur l'un des lecteurs. Toujours, les messages ressemblaient beaucoup à ceux-ci:
Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050] res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd] Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Apr 18 00:20:15 hope kernel: [307085.641010] 27 34 6a 0c
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd] Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1
Chaque erreur se plaignait d'un numéro de secteur différent et était accompagnée d'un délai de plusieurs secondes pour l'utilisateur (moi) accédant au disque.
J'ai vérifié la sortie de smartctl et j'ai vu la sortie suivante (parties non pertinentes coupées):
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 193 193 051 Pre-fail Always - 1606
5 Reallocated_Sector_Ct 0x0033 194 194 140 Pre-fail Always - 0
196 Reallocated_Event_Count 0x0032 162 162 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 51
En regardant en arrière dans les journaux, j'ai constaté que les erreurs se produisaient en fait depuis quelques jours, principalement pendant les sauvegardes, mais aussi fréquemment lors d'une utilisation très légère (ce qui signifie environ chaque 5ème fois que j'essayais d'enregistrer un fichier texte). J'ai conclu que mon disque était en train de mourir, que le RAID-1 le traitait correctement et qu'il était temps de commander un disque de remplacement. J'ai commandé un nouveau disque.
À ma grande surprise, un jour plus tard, les erreurs ... ont cessé. Je n'avais rien fait pour les réparer. Je n'avais pas redémarré, je n'avais pas mis le lecteur hors ligne, rien. Mais les erreurs ont tout simplement cessé.
À ce stade, curieux de voir si les secteurs défectueux se trouvaient juste dans des parties inactives du disque maintenant, j'ai sorti le disque du RAID, l'ai remis dans le RAID et lui ai permis de terminer la resynchronisation complète qui a suivi. La resynchronisation s'est terminée sans aucune erreur, 9 heures plus tard (les disques de 2 To prennent un peu de temps).
De plus, la sortie de smartctl a légèrement changé, comme suit:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 193 193 051 Pre-fail Always - 1606
5 Reallocated_Sector_Ct 0x0033 194 194 140 Pre-fail Always - 43
196 Reallocated_Event_Count 0x0032 162 162 000 Old_age Always - 38
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
Donc, la partie de ce qui me fait bizarre est, bien sûr, "Depuis quand les mauvais disques se réparent-ils?"
Je suppose qu'il est possible qu'une très petite zone du lecteur se soit spontanément détériorée et que le lecteur ait simplement pris 3 jours (!) Avant que son code de réallocation de secteur ne se déclenche et qu'il mappe certains secteurs de rechange sur une mauvaise zone du disque ... Mais je ne peux pas dire que j'aie jamais vu cela se produire.
Quelqu'un d'autre a-t-il vu ce genre de comportement? Si oui, quelle a été votre expérience avec le lecteur par la suite? Est-ce que cela s'est reproduit? Le disque a-t-il finalement échoué complètement? Ou était-ce simplement un problème inexpliqué qui restait inexpliqué?
Dans mon cas, j'ai déjà le disque de remplacement (obtenu sous garantie), donc je vais probablement remplacer le disque de toute façon. Mais j'aimerais savoir si j'ai mal diagnostiqué cela d'une manière ou d'une autre. Si cela aide, j'ai une sortie complète «smartctl -a» à partir du moment où le problème s'est produit. C'est juste un peu long, donc je ne l'ai pas posté ici.
la source
Réponses:
Si une région physique spécifique de la surface du lecteur se détériore, jusqu'à ce que ces secteurs puissent être correctement cartographiés, vous obtiendrez des erreurs de lecture non récupérées lorsque vous essayez de lire les données qui ont été écrites dans cette zone. Le lecteur sait que les secteurs sont mauvais (après les échecs d'accès aux secteurs) mais ne peut pas remapper les secteurs car ils contiennent déjà des données. Si vous formatez le lecteur ou écrasez les "mauvais" secteurs, le lecteur aura alors la possibilité de cartographier les secteurs défectueux.
Une fois que les secteurs défectueux sont cartographiés et tant que la surface du lecteur ne tombe pas en panne, vous êtes en bonne forme.
Je ne connais pas suffisamment les modèles de panne de lecteur des lecteurs actuels pour savoir s'il existe une forte corrélation entre une partie de la surface du support qui va mal et le problème qui se propage ou se reproduit. S'il n'y a pas de corrélation, une fois que les mauvais secteurs ont été cartographiés, vous êtes en bonne forme. S'il est une corrélation, alors c'est le début de la fin pour le lecteur.
la source
La plupart des lecteurs modernes "vectoriseront" un bloc qui a mal tourné. Le lecteur dispose d'un pool de blocs de rechange et le micrologiciel les utilise pour remplacer tous les blocs connus du lecteur comme étant défectueux. Le lecteur ne peut pas effectuer ce remappage lorsqu'il ne parvient pas à LIRE un bloc car il ne peut pas fournir les données correctes. Il renvoie simplement "erreur de lecture". Il marque le bloc comme étant mauvais, donc si jamais le bloc se lit correctement, le bloc est vectorisé et les données correctes écrites dans le bloc de remplacement. Si jamais le système d'exploitation ÉCRIT dans un bloc qui est dans un état "sortie vecteur en attente", le bloc est vectorisé et les données écrites dans le bloc de remplacement.
Le logiciel RAID de Linux obtiendra, en cas d'erreur de lecture d'un périphérique, les données correctes des autres éléments du tableau, puis essaiera d'écrire à nouveau le bloc défectueux. Donc, si l'écriture fonctionne correctement, les données sont sûres, sinon, le lecteur fait juste ce qui précède, vecteurs le bloc, puis effectue l'écriture. Alors, le lecteur vient de se réparer avec l'aide du système de raid!
En supposant que de tels événements sont raisonnablement rares, il est probablement sûr de continuer. Si trop de blocs de remplacement sont utilisés, le lecteur peut avoir un problème. Il y a une limite au nombre de blocs de remplacement pouvant être vectorisés en blocs de rechange et cela dépend du variateur.
la source
Oui, je l'ai vu aussi, et dans des circonstances très similaires. Dans mon cas, c'est un disque Western Digital 1 To «vert» de qualité grand public (WD10EARS) qui a provoqué cette cascade sur moi. La
Current_Pending_Sectorvaleur brute SMART est passée de zéro à 6, puis à 8, ce qui a incité le démon de surveillance SMART à m'envoyer des e-mails inquiétants.J'ai
mdadm --failédité et--removerécupéré le lecteur à partir de la matrice et j'ai effectué une passe non destructivebadblocksdessus, et oui, il y avait apparemment plus de 2 douzaines de blocs défectueux. Lorsque le disque de remplacement est arrivé environ un jour plus tard, j'ai réparé la baie et la vie a continué.Peu de temps après, par pur ennui, j'ai relancé
badblockssur le disque "raté" pour voir s'il avait empiré. Au contraire, le lecteur s'était complètement "réparé": zéro mauvais bloc! Secouant la tête, je l'ai essuyé et mis de côté pour être recyclé ou donné.La leçon: n'utilisez pas de disques grand public dans les serveurs, sauf si vous êtes disposé et capable de supporter toutes sortes de bizarreries et de manque de fiabilité. Corollaire: ne faites pas de bon marché sur les composants du serveur, car vous finirez par les payer de toute façon, en plus de temps et d'aggravation.
la source
Il est courant dans les environnements de serveur de supprimer les disques qui ont déjà montré de telles erreurs, corrigées ou non. Les erreurs dures de secteur peuvent être un signe de dommages physiques de la surface au support - et si vous rayez une surface, vous déplacez généralement le matériau sur les côtés de la rayure et obtenez une bavure plus haute que le plan de cette surface - ou de la poussière abrasive (verre! ). Les deux ont tendance à être plutôt dommageables pour un système mécanique qui repose sur un coussin d'air très mince entre deux surfaces supposées parfaitement lisses ... c'est pourquoi les erreurs moyennes une fois qu'elles commencent à atteindre un certain nombre ont tendance à se multiplier plutôt plus rapidement.
la source