Was kann an dieser HDD defekt sein?

[geohei]

Hallo.

Ich habe hier eine HDD, die mir kürzlich in einem RAID Array eingegangen ist. Media Error Count war fast dreistellig. Der RAID Controller (Areca ARC-1210) hat sie nach einigen Reparaturversuchen rausgeschmissen.

WDC WD2002FYPS-01U1B0
SATA/300
2 TB
Das Ding ist 13 Jahre alt !!!

CrystalDiskInfo (yellow):
- Reallocated Sector Count: 147/147/140 0000000001A4
- Current Pending Sector Count: 198/197/0 000000000000

Ich habe sie nachher in einer USB Bay zum Spaß etwas analysiert. Formatieren und schreiben funktioniert, dauert aber ewig (= Tage). Schreiben mit h2testw macht #10 MB/s (sollte etwa 130 MB/s sein). Lesen funktioniert normal und ohne Fehler mit 130 MB/s.

Ich habe die Platte natürlich abgeschrieben, möchte aber aus Interesse wissen/verstehen wie es technisch möglich ist, dass das Formatieren/Schreiben Faktor 13 langsamer ist als sonst. Was kann da defekt sein?

 

[TanteCharlie]

...

 

[soulstyle]

Defragmentiert?

 

[geohei]

...

?

Defragmentiert?

Wenn man die Platte aus dem RAID nimmt ist nichts mehr lesbar. Also zuerst formatieren. Danach brauch man nichts mehr zu defragmentieren weil nichts mehr da ist.

 

[Inzersdorfer]

420 defekte Sektoren wurden durch Reservesektoren ersetzt.

Um zu versuchen die Platte zu beurteilen bräuchte es den ganzen Screenshot von CrystalDiskInfo, dabei das Fenster mit der Maus an den Rändern soweit aufziehen bis alle Spalten und Zeilen vollständig sichtbar sind.

 

[geohei]

Ich nehme an die 420 kommen von 0x1A7 (423 Sektoren).
Hier der gewünschte Screenshot.
Bin gespannt ...

 

[bingo88]

Defekte Sektoren werden häufig erst beim Schreiben neu gemappt, sofern noch Reservesektoren verfügbar sind. Das dauert aber, bis erkannt wird, dass ein Sektor defekt ist. In Summe dürfte das zum Einbruch der Schreibleistung führen. Ich hatte das auch schon bei Platten, da trat das Problem zum Teil schon beim Lesen auf.

 

[Hatuja]

Ein defekt einer HDD kann viele Gründe haben. Bei einer solch alten HDD wird sie einfach "physikalisch" abgenutzt sein. Die mechanische Belastung sorgt halt für Abnutzung der beweglichen Teile. Der Motor, der die Platter dreht, läuft nicht mehr "rund" und die "Aufhängung" der Schreib-/Leseköpfe verliert an Präzision. Über die Jahre sorgt das dafür, dass die Platter beschädigt werden, weil z.B. ein Schreib-/Lesekopf immer mal wieder "über den Platter schrammt". Oder die Sektoreinteilung auf den Plattern wird an bestimmten Stellen vom Schreib-/Lesekopf nicht mehr "getroffen".

Dadurch können an diesen Stellen auf den Plattern die Daten nicht mehr korrekt gelesen und/oder geschrieben, also nicht korrekt bzw. nicht eindeutig magnetisierten werden.

Das merkt die HDD und führt den Vorgang an dieser Stelle nochmals durch.
Dadurch, dass nun der Schreib-/Lesekopf nicht nur einmal, sondern mehrmals über die selben Sektoren fahern muss, bricht dann die Lese- und Schreibgeschwindigkeit ein.

 

[Inzersdorfer]

709 weitere Sektoren können nicht gelesen werden (ID-C5), da hängt das OS gerne einmal beim Lesen.

2061 Schreibfehler, bei denen die Schreib/Leseeinheit außerhalb ihrer vorgesehenen Position war, die sind der Grund warum die HDD beim Schreiben so in die Knie geht. Das ist ein mechanischer Defekt.

 

[geohei]

Defekte Sektoren werden häufig erst beim Schreiben neu gemappt, sofern noch Reservesektoren verfügbar sind. Das dauert aber, bis erkannt wird, dass ein Sektor defekt ist. In Summe dürfte das zum Einbruch der Schreibleistung führen. Ich hatte das auch schon bei Platten, da trat das Problem zum Teil schon beim Lesen auf.

AFAIK wird beim Lesen gemappt. Beim Schreiben wird einfach geschrieben, ohne read-after-write oder failed sector detection, und somit kann ein fehlerhafter Sektor beim Schreiben nicht erkannt werden. Beim Lesen kann hingegen ein Fehler entdeckt werden. Dann wird mit diversen Techniken versucht den Sektor doch noch zu recovern. Wenn dies gelingt, dann wird gemappt. Das war mein Verständnis der Abfolge. Da meine HDD sehr langsam schreibt, und das über die ganze Platte, wäre es nicht mit einem mapping beim Schreiben zu erklären, zumal die danach gelesenen Sektoren bis zu 95% der Platte fehlerfrei gelesen werden können (h2testw).

Das merkt die HDD und führt den Vorgang an dieser Stelle nochmals durch.
Dadurch, dass nun der Schreib-/Lesekopf nicht nur einmal, sondern mehrmals über die selben Sektoren fahern muss, bricht dann die Lese- und Schreibgeschwindigkeit ein.

Ist es eigentlich ein gemeinsamer Lese-/Schreibkopf oder sind beide getrennt? AFAIK ist es eine Unit, sind also gemeinsam. Wenn sie getrennt wären würde es den Unterschied zwischen Lese- und Schreibgeschwindigkeit erklären.
Hier konnte ich das auch nicht in Erfahrung bringen

709 weitere Sektoren können nicht gelesen werden (ID-C5), da hängt das OS gerne einmal beim Lesen.

2061 Schreibfehler, bei denen die Schreib/Leseeinheit außerhalb ihrer vorgesehenen Position war, die sind der Grund warum die HDD beim Schreiben so in die Knie geht. Das ist ein mechanischer Defekt.

Danke für die Erklärungen und die Hilfe mit dem Lesen der SMART Daten.
Ist jetzt alles klarer.

 

[Hatuja]

[..]
Ist es eigentlich ein gemeinsamer Lese-/Schreibkopf oder sind beide getrennt? AFAIK ist es eine Unit, sind also gemeinsam. Wenn sie getrennt wären würde es den Unterschied zwischen Lese- und Schreibgeschwindigkeit erklären.
Hier konnte ich das auch nicht in Erfahrung bringen
[...]

Ja, der Magnetkopf mit Lese- und Schreibeinheit ist in der Regel eine Einheit.
Beim lesen muss lediglich das Elektromagnetische Feld gemessen werden. Das geht deutlich schneller, als das Feld neu zu schreiben. Außerdem wird normalerweise nach dem Schreiben immer kontrolliert, ob der Vorgang auch erfolgreich war. Du hast also pro Schreibvorgang noch mal einen Lesevorgang.

 

[Inzersdorfer]

Außerdem wird normalerweise nach dem Schreiben immer kontrolliert

Unter Windows wird NICHT kontrollgelesen, hier werden Schreibfehler nur dann registriert wenn dabei die Schreib/Leseeinheit auerhalb ihrer vorgesehenen Position war!

 

[Hatuja]

Unter Windows wird NICHT kontrollgelesen, hier werden Schreibfehler nur dann registriert wenn dabei die Schreib/Leseeinheit auerhalb ihrer vorgesehenen Position war!

Das was ich meine hat nichts mit dem OS zu tun, sondern spielt sich alles im Controllers der HDD ab.
Und auf "Software"-Ebene kümmert sich um solche Checks auch nicht das Betriebssystem, sondern das Filesystem.
Unter Windows "Workstation" und Windows Server bietet das z.B. das Hauseigene ReFS.

 

[Inzersdorfer]

Eine Hardwarebasierte Schreibverifizierung gibt es bei SATA HDD nicht, das ist ausschließlich eine Funktion bestimmter FS, hier im Forum hatte ich bisher keine ReFS Fälle vorliegen bemerkt, daher "Unter Windows...".

 

[bingo88]

AFAIK wird beim Lesen gemappt. Beim Schreiben wird einfach geschrieben, ohne read-after-write oder failed sector detection, und somit kann ein fehlerhafter Sektor beim Schreiben nicht erkannt werden. Beim Lesen kann hingegen ein Fehler entdeckt werden. Dann wird mit diversen Techniken versucht den Sektor doch noch zu recovern. Wenn dies gelingt, dann wird gemappt. Das war mein Verständnis der Abfolge. Da meine HDD sehr langsam schreibt, und das über die ganze Platte, wäre es nicht mit einem mapping beim Schreiben zu erklären, zumal die danach gelesenen Sektoren bis zu 95% der Platte fehlerfrei gelesen werden können (h2testw).

Normalerweise wird beim Lesen tatsächlich nur der defekte Sektor erkannt und der Pending sector count geht hoch. Geschrieben wird noch nichts, weil das mit Datenverlust einhergehen kann. Ich hatte mal ein Skript für Linux, mit dem man mittels hdparm und smartctl das Schreiben von defekten Sektoren forcieren konnte. Das Problem ist nur, dass man den bisherigen Inhalt des Sektors meistens nicht mehr lesen kann und daher die Daten futsch sind.

Vom Ablauf her war das wie folgt mit dem Skript: Starte einen extended smart Test. Dieser schlägt beim ersten gefundenen (pending) defekten Sektor fehl. Lies das Testergebnis aus, hier wird auch der Sektor genannt. Nutze hdparm um den defekten Sektor mit Nullen zu überschreiben (Sektor wird remappt, falls noch freie Reserven vorhanden sind). Lese mit hdparm aus, ob da nur noch Nullen kommen. Repeat.

Bei den von mir so "reparierten" Platten war das in der Tat so, dass beim Lesen des defekten Sektors mittels hdparm das ganze System für ein paar Sekunden einfrohr, bis die Fehlermeldung zurückkam. Natürlich ist die Platte danach nicht gesund, wenn man so viele kaputte Sektoren "fixt".

 

[geohei]

Normalerweise wird beim Lesen tatsächlich nur der defekte Sektor erkannt und der Pending sector count geht hoch. Geschrieben wird noch nichts, weil das mit Datenverlust einhergehen kann.

Sehr interessant was hier zu C4 und C5 steht.

Self-Monitoring, Analysis and Reporting Technology - Wikipedia

en.wikipedia.org

Es wird also mehrmals versucht zu lesen. Fragt sich nur ob die Firmware das bei inaktiver HDD von sich aus macht, oder ob ein gezielter/erneuter Leseversuch des OS der Auslöser dieser Opertaion ist.

Bei dedizierten RAID Platten ist das beispielsweise anders. Dort wird sofort gemappt, auch wenn der Sektor nicht mehr lesbar ist, da er mittels RAID Daten rekonstituiert werden kann.

Bei deinem Script sind aber dann die Daten futsch (wenn der pending sector nicht gelesen werden kann). Also kann man das nur auf eine Platte loslassen bei der man möglichen Datenverlust akzeptiert.

Was meine OP Frage angeht - Ich sehe keine logische Erklärung warum das Schreiben so lange dauert, außer eben Hardware Defekt, was alles sein kann.

Danke für die Antworten!