Interpretation der Ergebnisse von SMART und Badblocks
529
AlexOnLinux
Ich habe eine gebrauchte SSHD (Seagate Laptop SSHD - ST500LM000-1EJ162) bei ebay gekauft. In Bezug auf SMART ist die Festplatte möglicherweise beschädigt, ich bin mir nicht sicher. Um die SMART-Werte richtig zu interpretieren, brauche ich Ihre Hilfe.
In Bezug auf SMART habe ich eine enorme Menge an Raw-Read-Error und Seek-Error. Ich habe bis jetzt viele verschiedene Threads zu diesem Thema gelesen, und ich habe herausgefunden, dass diese beiden genannten Werte nahezu irrelevant sind, da es keine Standardisierung gibt, welche Art von Fehler auftreten muss, um diese beiden Werte zuzulassen (Raw- Read-Error's und Seek-Error's) erhöhen. Es ist der Hersteller, der dies entscheidet - im Allgemeinen: Seagate weist in der Regel hohe RAW-Werte für Raw-Read- und Suchfehler auf, während Western Digital in diesem Segment niedrige RAW-Werte aufweist. Aufgrund dieser Tatsache habe ich gelesen, dass es sinnlos wäre, die RAW-Werte dieser beiden Attribute zu interpretieren. Stattdessen sollte ich die Colloms mit dem Namen VALUE mit WORST und THRESHOLD vergleichen. Und hier kommt das nächste Problem. Nun ist es das Gegenteil: Ein höherer Wert als TRESHOLD wird bevorzugt.
Um es klarer zu machen, werfen Sie einen Blick auf den folgenden smartctl -a /dev/sdb/Ausschnitt
ID # ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE AKTUALISIERT WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 120 099 006 Pre-Fail Immer - 237676480
In Bezug auf SMART habe ich einen Raw_Read_Error_Rate mit einem RAW-Wert von 237676480. Dies scheint an erster Stelle gefährlich zu sein. Aber was die Kollome angeht, habe VALUE WORST THRESHich eine tatsächliche? WERT von 120. Der WORST-Fall war einmal 099 und wenn er unter THRESH 006 fällt, sollte die Platte als defekt betrachtet werden.
Gleiches gilt für den Reallocated-Sector. Je niedriger die Collom-Werte im Vergleich zum THRESH-Wert sind, desto schlechter ist der Plattenzustand.
Was mein SMART-Snippet anbelangt, so hat meine Festplatte nie etwas neu zugewiesen.
ID # ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE AKTUALISIERT WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-Fail Immer - 0
Werfen wir einen Blick auf Reported-Uncorrect-Error . Soweit ich weiß, zählen diese Fehler immer dann, wenn die Festplatte keinen fehlerhaften Sektor neu zuordnen kann, was dazu führt, dass die in einem solchen Sektor gespeicherten Daten verloren gehen.
ID # ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE AKTUALISIERT WHEN_FAILED RAW_VALUE 187 Reported_Uncorrect 0x0032 099 099 000 Old_age Immer - 1
In Bezug auf das SMART-Snippet oben hatte der Datenträger einen unkorrigierten Sektor während seiner Lebensdauer. In Bezug auf die Colloms VALUE und WORST besteht keine Notwendigkeit, einen Plattenfehler zu befürchten.
Ein weiteres Attribut ist Airflow-Temperature-Cel . Zuerst installierte ich die Festplatte in meinem 12 Jahre alten Laptop und rannte los badblocks, um meine Festplatte zu überprüfen. Während badblocksich mehrere Stunden lief, habe ich den SMART-Temperaturwert überprüft und sah, dass das Kollum VALUE gleich WORST war und beide unter THRESH sanken. Als RAW_VALUE hatte ich eine Aussage wie: DISK IS FAILING. Also entschied ich mich, meinen Laptop auszuschalten und die SSHD auf meinem Home-Server zu installieren, der einen besseren Luftstrom hat und neu gestartet wurde badblocks. Wenn Sie dieses SMART-Attribut jetzt überprüfen, beschreibt das collom WORST den Fall, der am Vortag in meinem Laptop stattgefunden hat, während das collom VALUE die tatsächliche Temperatur anzeigt. Beim Vergleich von VALUE mit THRESH ist die Temperatur in Ordnung. Der Versuch, RAW_VALUE zu interpretieren, ist etwas, mit dem ich Probleme habe. Hier der Ausschnitt
ID # ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE AKTUALISIERT WHEN_FAILED RAW_VALUE 190 Airflow_Temperature_Cel 0x0022 068 037 045 Old_age Always In_the_past 32 (0 120 37 26 0
Zu guter Letzt gibt es einige SMART-Informationen, die ich zu Lebzeiten noch nie in SMART-Ausgaben gelesen habe, und ich habe absolut keine Ahnung, wie diese zu interpretieren sind:
Fehler 4 beim Einschalten der Festplatte: 521 Stunden (21 Tage + 17 Stunden) Wenn der Befehl, der den Fehler verursacht hat, aufgetreten ist, war das Gerät aktiv oder im Leerlauf. Nach Abschluss des Befehls waren die Register: ER ST SC SN CL CH DH - - - - - - - 04 71 03 80 04 11 40 Befehle, die zu dem Befehl führten, der den Fehler verursacht hat, waren: CR FR SC SN CL CH D DC DC_Up_Time-Befehl / Funktionsname - - - - - - - - ---------------- ------------------ - ea 00 00 00 00 00 00 00 00: 13: 30.508 FLUSH CACHE EXT 61 00 08 00 09 9c 40 00 00: 13: 30.507 SCHREIBEN von FPDMA-QUEUED 61 00 08 78 e1 42 40 00 00: 13: 30.507 WRITE FPDMA QUEUED 61 00 28 f0 44 9d 40 00 00: 13: 30.507 SCHREIBEN von FPDMA-QUEUED 61 00 08 00 6f 71 47 00 00: 13: 29.805 WRITE FPDMA QUEUED Fehler 3 beim Einschalten der Festplatte aufgetreten: 519 Stunden (21 Tage + 15 Stunden) Wenn der Befehl, der den Fehler verursacht hat, aufgetreten ist, war das Gerät aktiv oder im Leerlauf. Nach Abschluss des Befehls waren die Register: ER ST SC SN CL CH DH - - - - - - - 04 51 00 a0 25 e7 06 Befehle, die zu dem Befehl führten, der den Fehler verursacht hat, waren: CR FR SC SN CL CH D DC DC_Up_Time-Befehl / Funktionsname - - - - - - - - ---------------- ------------------ - ea 00 00 00 00 00 00 00 00: 11: 47.000 FLUSH CACHE EXT 61 00 08 88 c4 a0 40 00 00: 11: 45.863 WRITE FPDMA QUEUED 60 00 08 40 d4 08 49 00 00: 11: 45.863 READ FPDMA QUEUED 61 00 08 00 09 9c 40 00 00: 11: 45.863 WRITE FPDMA QUEUED 60 00 12 19 47 5a 40 00 00: 11: 45.863 READ FPDMA QUEUED Fehler 2 beim Einschalten der Festplatte: 519 Stunden (21 Tage + 15 Stunden) Wenn der Befehl, der den Fehler verursacht hat, aufgetreten ist, war das Gerät aktiv oder im Leerlauf. Nach Abschluss des Befehls waren die Register: ER ST SC SN CL CH DH - - - - - - - 40 51 00 40 d4 08 09 Fehler: WP bei LBA = 0x0908d440 = 151573568 Befehle, die zu dem Befehl führten, der den Fehler verursacht hat, waren: CR FR SC SN CL CH D DC DC_Up_Time-Befehl / Funktionsname - - - - - - - - ---------------- ------------------ - 61 00 08 78 e1 42 40 00 00: 10: 28.019 WRITE FPDMA QUEUED 61 00 08 e0 96 a0 40 00 00: 10: 27.914 WRITE FPDMA QUEUED 61 00 08 98 95 a0 40 00 00: 10: 27.914 WRITE FPDMA QUEUED 61 00 08 70 95 a0 40 00 00: 10: 27.914 WRITE FPDMA QUEUED 61 00 08 58 95 a0 40 00 00: 10: 27.914 WRITE FPDMA QUEUED Fehler 1 trat beim Einschalten der Festplatte auf: 426 Stunden (17 Tage + 18 Stunden) Wenn der Befehl, der den Fehler verursacht hat, aufgetreten ist, war das Gerät aktiv oder im Leerlauf. Nach Abschluss des Befehls waren die Register: ER ST SC SN CL CH DH - - - - - - - 04 71 03 80 04 11 40 Befehle, die zu dem Befehl führten, der den Fehler verursacht hat, waren: CR FR SC SN CL CH D DC DC_Up_Time-Befehl / Funktionsname - - - - - - - - ---------------- ------------------ - ea 00 00 00 00 00 00 00 00: 35: 26.857 FLUSH CACHE EXT 61 00 08 00 09 9c 40 00 00: 35: 26.856 WRITE FPDMA QUEUED 61 00 08 ff ff ff 4f 00 00: 35: 26.161 WRITE FPDMA QUEUED 61 00 08 ff ff ff 4f 00 00: 35: 26.161 WRITE FPDMA QUEUED 61 00 08 ff ff ff 4f 00 00: 35: 26.160 WRITE FPDMA QUEUED
Aus den Beiträgen, die ich in verschiedenen Foren gelesen habe , wird empfohlen, die Festplatten auszutauschen, bevor sich die Dinge verschlechtern. Ich habe auch gelesen, wie einige Leute kommentieren, dass sie solche Datenträger mehrere Jahre lang verwenden konnten, bevor sie zu Tode kamen. Für mich ist das ein neues Land. Ich hatte noch nie eine Festplatte mit so vielen Fehlern. Wahrscheinlich hat der Besitzer die Festplatte vorher schlecht behandelt. Zum Beispiel, wenn er seinen Laptop viel schüttelte, oder die SATA-Anschlüsse passten nicht perfekt und verursachten auch Fehler. Wie gesagt, ich habe keine Ahnung, wie diese Parameter zu interpretieren sind. Es ist wie ein Experiment, das ich mit dieser Platte machen werde.
Ich habe die Diskette mit überprüft badblocks -wvs -b 4096 -o badblox.result /dev/sdbund hatte keine Fehler - NICHT KOPIEREN UND VERGNÜGEN, DASS BADBLOCKS BEFEHL !!! . Beim Vergleich der Ergebnisse smartctl -a /dev/sdbvor und nach der Ausführung stieg badblocksdie Anzahl von Raw_Read_Error_Rate und Seek_Error_Rate jedoch stark an, während alle anderen Attributwerte gleich blieben. Überprüfen Sie den Ausschnitt unten:
Vor dem Ausführen badblocks.
ID # ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE AKTUALISIERT WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 104 099 006 Pre-Fail Immer - 6995776 7 Seek_Error_Rate 0x000f 059 055 030 Pre-Fail Immer - 107395771838
Nachdem babdblocksfertig.
ID # ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE AKTUALISIERT WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 120 099 006 Pre-Fail Immer - 237676480 7 Seek_Error_Rate 0x000f 059 055 030 Pre-Fail Immer - 107395783395
Die gesamte SMART-Ausgabe kann auf PasteBin überprüft werden:
Ist meine Interpretation von Raw-Read und Seek-Error korrekt?
Null neu zugewiesene Sektoren zu haben, ist eine gute Sache?
Nur einen nicht neu zugewiesenen Fehler zu haben ist nicht so schlimm?
Null Fehler beim Laufen badblocksbedeutet, dass sich die Festplatte in einem guten Zustand befindet?
Wie muss ich den Fehler 1 bis Fehler 4 interpretieren ?
Noch einen Test, den ich machen sollte, abgesehen von dem Selbsttest smartctl -t long /dev/sdb, der tatsächlich ausgeführt wird?
1 Antwort auf die Frage
2
dirkt
Sehr schnell:
Rohwerte bedeuten nichts. Sie können von Firmware zu Firmware unterschiedlich sein. Versuchen Sie nicht, sie zu interpretieren, wenn Sie nicht genau wissen, was Ihr Rohwert für Ihre spezielle Hardware bedeutet. Manchmal ist es offensichtlich (Temperatur in Celsius), oft nicht.
Die Werte sind auf 100 normiert, niedriger ist schlechter. Wenn es 100 oder höher ist, müssen Sie sich keine Sorgen machen. Wenn sie unter 100 liegt, zeigt die Festplatte etwas Abnutzung. Wenn es sich der Schwelle oder unter ihr nähert, machen Sie sich Sorgen.
Alle Festplatten haben reine Lesefehler. Dies ist eine Folge der hohen Dichte heutiger Laufwerke und dafür ist die eingebaute Fehlerkorrektur gedacht.
Also: Ihre Rohdatenrate sieht gut aus. Ihre neu zugeteilte Sektorenquote ist exzellent, was bisher noch nicht ernsthaft passiert ist. Einige neu zugeteilte Sektoren sind kein Grund zur Sorge.
Ihre Temperatur ist aus irgendeinem Grund zu hoch. Überprüfen Sie, ob die Festplatte ordnungsgemäß abgekühlt ist. Die Suchfehlerrate ist zu hoch. Dies kann eine Folge einer zu hohen Temperatur sein, die dazu führt, dass sich das Metall etwas ausdehnt, wodurch sich die Kopfposition außerhalb der Spezifikationen bewegen kann.
Das einzige, worüber Sie sich Sorgen machen müssen, ist die richtige Kühlung. Wenn Sie dies schaffen können, sollten die Suchfehler zurückgehen, und an Ihrer Stelle würde ich die Festplatte behalten. (Aber natürlich machen Sie Backups, oder?)
Bearbeiten
Fehler 1-4 stammen aus einem Protokoll der fünf letzten Fehler, die auf der ATA-Schicht mitgeteilt wurden. Normalerweise bekommt man einen Header wie
SMART Error Log Version: 1 ATA Error Count: xxx (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX]
Man könnte also Befehls- und Merkmalswerte im ATA-Standard nachschlagen, um mehr Details über das Geschehene zu erfahren. Wenn jedoch von Zeit zu Zeit Fehler auftreten, ist dies an sich kein Grund zur Sorge: Der Embedded-Controller ist komplex, die Interaktion mit dem Host ist komplex, das Timing ist komplex. Wenn einige ungewöhnliche Umstände auftreten, ist dies eine Möglichkeit, einen Fehler zu erhalten. Andere Möglichkeiten sind Fehler in der Embedded-Controller-Firmware, die nur unter diesen ungewöhnlichen Umständen ausgelöst werden.
Nur wenn Fehler häufig auftreten und weiterhin auftreten, ist es an der Zeit, sich Sorgen zu machen, insbesondere wenn es sich immer um denselben Fehler handelt.
Sie haben drei Fehler, die nach einem Cache-Flush aufgetreten sind, und einer nach einem Schreibvorgang (LBA = logische Blockadresse). Zwei passierten zusammen, wahrscheinlich als Folge des gleichen Problems, und der eine vor und der danach passierte unabhängig voneinander. An Ihrer Stelle würde ich diese völlig ignorieren: Was auch immer sie verursacht hat, ist vorbei und es passiert nicht mehr.
Hey, danke für deine schnelle Antwort. Gut zu wissen, meine Interpretation war überhaupt nicht so schlecht. Könnten Sie mir auch eine Antwort geben, wie * Error1 * bis * Error 4 * zu verstehen ist?
AlexOnLinux vor 5 Jahren
0