Fehler beim Lesen der Festplatte, die… aufhören?

Meine Geschichte beginnt ganz einfach. Ich habe einen Light-Duty-Server unter Arch Linux, auf dem die meisten Daten auf einem RAID-1 gespeichert sind, das aus zwei SATA-Laufwerken besteht. Es funktionierte ungefähr 4 Monate ohne Probleme. Dann bekam ich plötzlich Lesefehler auf einem der Laufwerke. Die Nachrichten sahen immer sehr ähnlich aus:

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

Jeder Fehler beklagte sich über eine andere Sektornummer und ging mit einer Verzögerung von mehreren Sekunden für den Benutzer (mich) einher, der auf die Festplatte zugreift.

Ich habe die Smartctl-Ausgabe überprüft und die folgende Ausgabe gesehen (irrelevante Teile abgeschnitten):

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

Rückblickend in den Protokollen stellte ich fest, dass die Fehler tatsächlich einige Tage lang aufgetreten waren, hauptsächlich während Sicherungen, aber auch häufig bei sehr geringem Gebrauch (dh etwa jedes fünfte Mal, wenn ich versuchte, eine Textdatei zu speichern). Ich kam zu dem Schluss, dass meine Festplatte im Sterben lag, dass das RAID-1 sie ordnungsgemäß handhabte und dass es Zeit war, eine Ersatzfestplatte zu bestellen. Ich habe eine neue Diskette bestellt.

Zu meiner großen Überraschung hörten die Fehler einen Tag später auf. Ich hatte nichts getan, um sie zu reparieren. Ich hatte nicht neu gestartet, das Laufwerk nicht offline geschaltet, nichts. Aber die Fehler hörten einfach auf.

Zu diesem Zeitpunkt nahm ich die Festplatte aus dem RAID heraus, legte sie wieder in das RAID ein und erlaubte ihr, die anschließende vollständige Neusynchronisierung abzuschließen, um zu sehen, ob sich die fehlerhaften Sektoren gerade in nicht genutzten Teilen der Festplatte befanden. Die Neusynchronisierung wurde 9 Stunden später fehlerfrei abgeschlossen (2-TB-Festplatten benötigen eine Weile).

Außerdem hat sich die Smartctl-Ausgabe wie folgt etwas geändert:

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

Der Teil davon, der mich verrückt macht, ist natürlich: "Seit wann reparieren sich fehlerhafte Festplatten selbst?"

Ich nehme an, es ist möglich, dass ein sehr kleiner Bereich des Laufwerks spontan fehlerhaft wurde und dass das Laufwerk nur 3 Tage (!) Dauerte, bevor der Code für die Neuzuweisung des Sektors aktiviert wurde und einige Ersatzsektoren über einen fehlerhaften Bereich der Festplatte abgebildet wurden ... Aber ich kann nicht sagen, dass ich das jemals gesehen habe.

Hat jemand anderes diese Art von Verhalten gesehen? Wenn ja, wie war Ihre Erfahrung mit der Fahrt danach? Ist es wieder passiert? Ist die Festplatte schließlich vollständig ausgefallen? Oder war es nur eine ungeklärte Panne, die ungeklärt blieb?

In meinem Fall habe ich bereits das Ersatzlaufwerk (im Rahmen der Garantie erhalten), daher werde ich das Laufwerk wahrscheinlich trotzdem ersetzen. Aber ich würde gerne wissen, ob ich das irgendwie falsch diagnostiziert habe. Wenn es hilft, habe ich eine vollständige 'smartctl -a'-Ausgabe, als das Problem auftrat. Es ist nur ein bisschen lang, also habe ich es hier nicht gepostet.

Wenn ein bestimmter physischer Bereich der Laufwerksoberfläche fehlerhaft ist, werden bis zum erfolgreichen Zuordnen dieser Sektoren nicht wiederhergestellte Lesefehler angezeigt, wenn Sie versuchen, Daten zu lesen, die in diesen Bereich geschrieben wurden. Das Laufwerk weiß, dass die Sektoren fehlerhaft sind (nach dem Fehler beim Zugriff auf die Sektoren), kann die Sektoren jedoch nicht neu zuordnen, da sie bereits Daten enthalten. Wenn Sie das Laufwerk formatieren oder die "fehlerhaften" Sektoren überschreiben, hat das Laufwerk die Möglichkeit, die fehlerhaften Sektoren zuzuordnen.

Sobald die fehlerhaften Sektoren zugeordnet sind und solange nicht mehr von der Laufwerksoberfläche ausfällt, sind Sie in guter Verfassung.

Ich weiß nicht genug über Laufwerksfehlermodelle aktueller Laufwerke, um zu wissen, ob eine große Korrelation zwischen einem fehlerhaften Teil der Medienoberfläche und dem Problem besteht, das sich ausbreitet oder erneut auftritt. Wenn es keine Korrelation gibt, sind Sie in guter Verfassung, sobald die schlechten Sektoren zugeordnet sind. Wenn es ist eine Korrelation, dann ist dies der Anfang vom Ende für den Antrieb.

Die meisten modernen Laufwerke "vektorisieren" einen Block, der schlecht geworden ist. Das Laufwerk verfügt über einen Pool von Ersatzblöcken, und die Firmware verwendet diese, um alle Blöcke zu ersetzen, von denen bekannt ist, dass sie fehlerhaft sind. Das Laufwerk kann diese Neuzuordnung nicht durchführen, wenn es einen Block nicht LESEN kann, da es nicht die richtigen Daten liefern kann. Es wird nur "Lesefehler" zurückgegeben. Der Block wird als schlecht markiert. Wenn der Block also jemals korrekt gelesen wird, wird der Block vektorisiert und die korrekten Daten in den Ersatzblock geschrieben. Wenn das Betriebssystem jemals an einen Block schreibt, der sich in einem Zustand "Vektorausgang anstehend" befindet, wird der Block vektorisiert und die Daten in den Ersatzblock geschrieben.

Bei einem Linux-Software-Raid werden beim Abrufen eines Lesefehlers von einem Gerät die korrekten Daten von anderen Elementen im Array abgerufen und anschließend versucht, den fehlerhaften Block erneut zu schreiben. Wenn der Schreibvorgang in Ordnung ist, sind die Daten sicher. Wenn nicht, führt das Laufwerk nur die oben genannten Schritte aus, vektorisiert den Block und führt dann den Schreibvorgang durch. Also, das Laufwerk hat sich mit Hilfe des Raid-Systems gerade selbst repariert!

Unter der Annahme, dass solche Ereignisse relativ selten sind, ist es wahrscheinlich sicher, weiterzumachen. Wenn zu viele Ersatzblöcke verwendet werden, liegt möglicherweise ein Problem mit dem Laufwerk vor. Es gibt eine Begrenzung, wie viele Ersatzblöcke in Ersatzblöcke übertragen werden können, und dies ist eine Funktion des Laufwerks.

Ja, ich habe das auch gesehen und unter sehr ähnlichen Umständen. In meinem Fall war es ein "Consumer" Western Western 1 TB "Green" -Laufwerk (WD10EARS), das mich beeindruckt hat. Der SMART- Current_Pending_SectorRohwert ging von null auf 6 und dann auf 8 und veranlasste den SMART-Überwachungsdämon, mir einige bedrohliche E-Mails zu senden.

Ich mdadm --failed und --removed das Laufwerk aus dem Array und lief einen nicht-destruktiven Pass von badblocksüber es, und ja, es gab anscheinend mehr als 2 Dutzend schlechte Blöcke. Als das Ersatzlaufwerk ungefähr einen Tag später eintraf, reparierte ich das Array und das Leben ging weiter.

Kurz danach wiederholte ich aus purer Langeweile badblocksdie "gescheiterte" Fahrt, um zu sehen, ob sie sich verschlechtert hatte. Im Gegenteil, das Laufwerk hatte sich komplett "repariert": keine fehlerhaften Blöcke! Kopfschüttelnd wischte ich es ab und legte es beiseite, um es zu recyceln oder zu spenden.

Die Lektion: Verwenden Sie keine Consumer-Laufwerke in Servern, es sei denn, Sie sind bereit und in der Lage, alle Arten von Verrücktheit und Unzuverlässigkeit in Kauf zu nehmen. Fazit: Verbilligen Sie Serverkomponenten nicht billig, da Sie letztendlich ohnehin dafür bezahlen müssen, in zusätzlicher Zeit und Ärger.

In Serverumgebungen ist es üblich, Laufwerke zu verwerfen, bei denen jemals solche Fehler aufgetreten sind, ob behoben oder nicht. Sektorharte Fehler können ein Zeichen für eine physische Oberflächenbeschädigung des Mediums sein - und wenn Sie eine Oberfläche zerkratzen, verschieben Sie normalerweise entweder Material an die Seiten des Kratzers und erhalten einen Grat, der höher als die Ebene dieser Oberfläche ist - oder Schleifstaub (Glas! ). Beide sind für ein mechanisches System, das auf einem sehr dünnen Luftkissen zwischen zwei Oberflächen beruht, das als vollkommen glatt angenommen wird, eher schädlich. Deshalb vermehren sich mittlere Fehler, sobald sie eine bestimmte Anzahl erreichen, eher schneller.