SAS Platten - > Smartctl: Error counter log / Failure Prediction Threshold Exceeded

antilope114

Enthusiast
Thread Starter
Mitglied seit
12.01.2012
Beiträge
657
SAS Platten - > Smartctl: Error counter log / Failure Prediction Threshold Exceeded

Habe gerade mal nach einem Jahr Smartinfos für meine SAS_Platten ausgelesen.
Was mich etwas stutzig macht sind die Werte für "Errors corrected by ECC" sowie der Status "FAILURE PREDICTION THRESHOLD EXCEEDED"

Konkret handelt es sich um einen zfs mirror, die Platten (2 Seagate SAS 3 TB Constellation ES.2) hängen an einem LSI Controller (SAS 2008).

Könnte es mit dem Solaris mpt2sas-Treiber für den Controller zu tun haben? OS ist Solaris 11.

andreas@linda:/dev/rdsk# smartctl -d scsi -a /dev/rdsk/c0t5000C50034013A43d0
smartctl 5.40 2010-10-16 r3189 [i386-pc-solaris2.11] (local build)
Copyright (C) 2002-10 by Bruce Allen, smartmontools

Device: SEAGATE ST33000650SS Version: 0002
Serial number: Z2900F1***********
Device type: disk
Transport protocol: SAS
Local Time is: Sat May 12 19:25:59 2012 CEST
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: FAILURE PREDICTION THRESHOLD EXCEEDED [asc=5d, ascq=0]

Current Drive Temperature: 51 C
Drive Trip Temperature: 68 C
Manufactured in week 14 of year 2011
Specified cycle count over device lifetime: 10000
Accumulated start-stop cycles: 139
Specified load-unload count over device lifetime: 300000
Accumulated load-unload cycles: 139
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 145273667
Blocks received from initiator = 3171265677
Blocks read from cache and sent to initiator = 1082207945
Number of read and write commands whose size <= segment size = 35622077
Number of read and write commands whose size > segment size = 69369
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 7192.52
number of minutes until next internal SMART test = 36

Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 1586997246 0 0 1586997246 0 35258.752 0
write: 0 0 0 0 0 1661.050 0

Non-medium error count: 35
No self-tests have been logged
Long (extended) Self Test duration: 27600 seconds [460.0 minutes]
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
die Auswertung von smart-parametern ergibt für smartmontools, dass die Platte statistisch gesehen als fehlerhaft behandelt und ausgetauscht werden sollte;
der Schwellenwert ab dem so verfahren werden sollte (nach Vorstellung dieser Software) ist sogar überschritten (darum ist wohl auch kein hochgerechnetes Ausfalldatum mehr angegeben);
aber die Software versucht anhand der von der Platte gelieferten Werte eine Voraussage zu treffen, die als solche nie mit Notwendigkeit, sondern immer nur mit einer gewissen Wahrscheinlichkeit eintritt oder auch nicht eintritt
die Platte kann also durchaus noch problemlos weiterfunktionieren, wie lange weiss man nicht
ausserdem muss die Software die Werte, die die Platte liefert, auch richtig interpretieren

da du smart aktiviert hast (was übrigens ein klein wenig Performance kostet), kann man davon ausgehen, dass die Auswertungen der smart-statistik nicht ignoriert werden sollen, also tausch die Platte aus
Sicherungskopien sind ohnehin klar
darüberhinaus würde ich Rücksprache mit Seagate nehmen

die Platte lief in dem Betriebsjahr fast genau an akkumuliert 300 Tagen, also jedenfalls nicht so ganz 24/7, sie ist in der Zeit 139mal gestartet worden
je nachdem wie die Platte untergebracht ist (eventuell so ne enclosure-sardinenbüchse durch die ein zu klein geratener Lüfter versucht einen Hauch von Luft zu quälen), wird sie für meine Begriffe auch ein wenig zu warm
 
Zuletzt bearbeitet:
die Auswertung von smart-parametern ergibt für smartmontools, dass die Platte statistisch gesehen als fehlerhaft behandelt und ausgetauscht werden sollte;
der Schwellenwert ab dem so verfahren werden sollte (nach Vorstellung dieser Software) ist sogar überschritten (darum ist wohl auch kein hochgerechnetes Ausfalldatum mehr angegeben);
aber die Software versucht anhand der von der Platte gelieferten Werte eine Voraussage zu treffen, die als solche nie mit Notwendigkeit, sondern immer nur mit einer gewissen Wahrscheinlichkeit eintritt oder auch nicht eintritt
die Platte kann also durchaus noch problemlos weiterfunktionieren, wie lange weiss man nicht
ausserdem muss die Software die Werte, die die Platte liefert, auch richtig interpretieren

Ja, was es heißt weiß ich, ich frage mich nur, ob das z.B. an einem Bug im mpt2sas Treibermodul von Solaris liegen kann. Ich habe außerdem vor 3 Monaten den Controller auf die neueste Firmware geflasht - ich weiß nicht, inwieweit da vorher Bugs vorhanden waren die das Ergebnis vermutlich verfälscht haben? Oder ist das komplett unabhängig von den Platten?

Die zweite Platte hat nämlich ähnliche Fehlerwerte und meldet auch Failure Prediction Threshold Exceeded .... das wundert mich.

da du smart aktiviert hast (was übrigens ein klein wenig Performance kostet), kann man davon ausgehen, dass die Auswertungen der smart-statistik nicht ignoriert werden sollen, also tausch die Platte aus
Sicherungskopien sind ohnehin klar
darüberhinaus würde ich Rücksprache mit Seagate nehmen

Wie gesagt ist ja ein Raid 1 aus zwei solcher SAS Platten (angeblich beide mit Failure Prediction Threshold Exceeded) ... aber werde Seagate mal eine E-Mail schicken und nachfragen. Waren immerhin auch nicht so ganz günstig :)

je nachdem wie die Platte untergebracht ist (eventuell so ne enclosure-sardinenbüchse durch die ein zu klein geratener Lüfter versucht einen Hauch von Luft zu quälen), wird sie für meine Begriffe auch ein wenig zu warm

Es gibt 4 PWM gesteuerte Lüfter im Gehäuse, zwei Festplattenkäfige mit jeweils einem 120mm Lüfter vorne sowie 2x140 mm exhaust oben und hinten. Ich glaube nicht, dass das ein Problem war.
 
Deaktivierung der Fehlerkorrektur, böse!

Hab die Tabelle gerade nicht im Kopf, die Zitatfunktion vom Forum erhält die Einteilung leider nicht wirklich.
Aber bei 1 ECC-Recovery pro 512Byte Sektor: 1586997246*512/1024/1024 = 774901MiB. Also durchaus im Rahmen.
Wenn du willst, kannst du ja anhand von Linux sdparm utility mal mit mit dem RC bit spielen.

Habe es zwar schon einmal angegeben, aber hier noch einmal:
The Read Continuous (RC) bit, when set to one, requests the disc drive to transfer the requested data length
without adding delays (for retries or ECC correction) that may be required to insure data integrity. The disc
drive may send erroneous data in order to maintain the continuous flow of data.
Zuvor solltest du aber das remapping deaktivieren. Ansonsten weist die Firmware der HDD jedem nicht sofort lesbaren Sektor einen anderen zu.
Reallocations are performed when the ARRE bit (for reads) or AWRE bit (for writes) is one, the
RC bit is zero, and the Recovery Time Limit for the command has not yet been met.
RRC Read retry count
sollte auch noch auf 0 gesetzt werden.
Ich habe bewusst nicht eine Schritt für Schritt Anleitung geschrieben, da man so etwas nur auf nicht benötigten Systemen nur zum testen machen sollte. Niemals mit der System HDD!

Als Test kannst du z.B. eine größere Datei mit mehreren hundert MB oder auch ein paar GB nehmen und von dieser die Prüfsumme vergleichen mit einer zuvor schon heraus gefundenen :)
 
Bei der zweiten Platte sind es angeblich 2277577247 ECC Errors corrected. Aber was meinst du mit
Also durchaus im Rahmen
?

Dass beide Platten in etwa dieselbe Meldung ausgeben macht mich halt stutzig. Ich weiß auch nicht, inwiefern ZFS da eine Rolle spielt - bei sämtlichen scrubs (im Schnitt 1-2 pro Woche) mit über 2,5T Nutzdaten gab es nicht einen Fehler der korrigiert werden musste.

Ich werde jetzt trotzdem nicht anfangen an den Einstellungen rumzuspielen, da kenne ich mich einfach nicht gut genug aus. Meine Tendenz wäre derzeit laufen lassen und beobachten. Im Worst Case werden wohl nicht beide Platten gleichzeitig den Geist aufgeben sodass ich immer noch bei Ausfall einen Spare nachschieben kann. Außerdem schiebe ich alle 24 h die wichtigsten Daten auf einen Backup-Rechner...
 
Zuletzt bearbeitet:
Es wäre zum verdeutlichen gewesen, dass "moderne" HDDs ohne eine vernünftige ECC Fehlerkorrektur nicht mehr zuverlässig funktionieren.

Long (extended) Self Test duration: 27600 seconds [460.0 minutes]
Mehr als sieben einhalb Stunden, ich weiß schon, warum ich nicht mehr als max. 2 Platter HDDs mag...
 
Hab die Tabelle gerade nicht im Kopf, die Zitatfunktion vom Forum erhält die Einteilung leider nicht wirklich.
Aber bei 1 ECC-Recovery pro 512Byte Sektor: 1586997246*512/1024/1024 = 774901MiB. Also durchaus im Rahmen.

Seit einer Stunde sind da ca. 5 Millionen dazugekommen ... Wenn ich Daten auf den Raid-Verbund schreibe kann ich live dabei zusehen, wie der Zähler nach oben geht...:hmm:
 
Zuletzt bearbeitet:
Also hier nochmal die Antwort von Seagate

Third party software does not ready our smart parameters correctly. If you want to test the drives please do so by running Seatools. You can check there by running the short and long tests, and checking to see if the Smart indicator has tripped.

Für mich aber eine typische Support-Antwort, denn natürlich ist der Smart-Status aussagefähig, aber wohl nicht hinreichend für RMA.

Seatools kann ich momentan nicht laufen lassen weil mein LSI-Controller trotz direkt passthrough in meiner solaris vm nicht erkannt wird.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh