Lowlevel-Format = Zero-Fill?

Ernst@at schrieb:
HDTune setzt seine I/Os auf physischer Ebene ab, während im Normalfall sonst jeder Zugriff über das Filesystem abgehandelt wird und daher auch dessen interne Recovery abläuft. Das war damit gemeint - ich entschuldige mich für die unklare Ausdrucksweise es hätte korrekt "... die Filesystem-interne Recovery umgangen wird" heißen sollen.
Ah, so war das gemeint. Alles klar. Danke.

@_TK_
Ich habe ein bisschen weiter recherchiert und in einer beliebig überprüften OEM-Specifiation (7K1000.C Serie) von Hitachi folgendes gefunden:

Hitachi schrieb:
Non recovered read errors

When a read operation is failed after defined Error Recovery Procedure (ERP) is fully carried out, a hard error is reported to the host system. This location is registered internally as a candidate for the reallocation (Anmk. vermutlich "Current Pending"-Liste). When a registered location is specified as a target of a write operation, a sequence of media verification is performed automatically. When the result of this verification meets the criteria, this sector is reallocated.
Das spricht dann wieder für die Ausführungen in der Smartmontools-FAQ, dass ein "Pending Sector" ein nicht mehr lesbarer Sektor ist (vorausgesetzt natürlich, dass ich das korrekt interpretiert habe).

Was zeigt smartctl denn genau an, wenn du das Treiben beobachtest? Streng genommen gilt das oben ja nur für Hitachi Laufwerke. Möglicherweise arbeiten Laufwerke anderer Hersteller anders.

Ich poste mal den gesamten Abschnitt:

Hitachi schrieb:
Auto Reassign Function

The sectors those show some errors may be reallocated automatically when pecific conditions are met. The spare tracks for reallocation are located at regular intervals from Cylinder 0. The conditions for auto-reallocation are described below.

Non recovered write errors

When a write operation can not be completed after the Error Recovery Procedure (ERP) is fully carried out, the sector(s) are reallocated to the spare location. An error is reported to the host system only when the write cache is disabled and the auto reallocation is failed. If the write cache function is ENABLED, and when the number of available spare sectors reaches 0 sectors, both auto reassign function and write cache function are disabled automatically.

Non recovered read errors

When a read operation is failed after defined ERP is fully carried out, a hard error is reported to the host system. This location is registered internally as a candidate for the reallocation. When a registered location is specified as a target of a write operation, a sequence of media verification is performed automatically. When the result of this verification meets the criteria, this sector is reallocated.

Recovered read errors

When a read operation for a sector failed once then recovered at the specific ERP step, this sector of data is reallocated automatically. A media verification sequence may be run prior to the relocation according to the pre-defined conditions.
Leider werden keine genaueren Angaben über das "Error Recovery Procedure" gemacht. Es ist also nur ein grober Überblick des Ablaufs.
 
Zuletzt bearbeitet:
Madnex schrieb:
Das spricht dann wieder für die Ausführungen in der Smartmontools-FAQ, dass ein "Pending Sector" ein nicht mehr lesbarer Sektor ist (vorausgesetzt natürlich, dass ich das korrekt interpretiert habe).

Dafür spricht auch die Praxis: Ich hatte hier eine Platte, die einen 'pending sector' meldete. Beim runtersichern der Daten ist der Wert immer weiter angestiegen (und entsprechend dazu auch die 'raw read error rate').
Von der Theorie her: Es werden die Daten und ECC-Daten geschrieben - wird danach nochmal verifiziert? Das geht aus den Hitach-Specs jetzt (für mich) nicht so recht hervor.
Sollte da nicht zusätzlich verifiziert werden, kann ein Fehler ja auch erst beim auslesen auffallen - schließlich wird da ja erst geprüft, ob die Daten nocht korrekt sind.
 
Es werden die Daten und ECC-Daten geschrieben - wird danach nochmal verifiziert?
Nein. "Write and Verify" wird in dieser Liga nicht gespielt.
Im Normalbetrieb würde das einen zusätzlichen Zeitverlust von einer weiteren Umdrehung (~8ms) bedeuten.
Bei der Überprüfung eines "Pending Sectors" auf die Notwendigkeit einer Auslagerung ist es allerdings Bestandteil der ERP.
 
Zuletzt bearbeitet:
Von älteren Maxtor Serien ist mir bekannt, dass sie innerhalb der ersten 10 Systemstarts eine Leseüberprüfung nach einen Schreibzugriff durchführen (was natürlich Leistung kostet). Mit einem Tool (Wvset) konnte man dieses Verhalten sofort deaktivieren oder (glaube ich) auch dauerhaft aktivieren. Wie das bei aktuellen Laufwerken, auch der anderen Hersteller (Maxtor existiert ja nur noch als Markenname), innerhalb der ersten Betriebsstunden aussieht, weiß ich allerdings nicht.
 
Zuletzt bearbeitet:
Moin!
Habe gestern einen Test mit einer alten Fujitsu 2,5" 40GB (MHT2040AH) durchgeführt:
Anfangs standen 1 "pending", und 2 "offline uncorrectable" in der Liste. Nach HDTUNE-Lesetest waren es 8 "pending" und 9 "offline uncorrectable" geworden.
Dann Linux gestartet, einmal komplett gelesen und geschrieben -> 5 pending, 9 nicht korrigierbar.
Leider ist die Angabe der ausgelagerten (relallocated) Sektoren bei diesem Modell nicht ohne weiteres auswertbar, d.h. ich werde mir nachher erstmal die G-Liste anschauen. Bin aber noch unterwegs, außerdem ist da noch die Familie...

Geschriebene Daten werden bei neueren Platten sicher nicht mehr kontrolliert wie von Madnex beschrieben - die Kunden würden sie wohl wegen mangelnder Performance gleich umtauschen wollen. Außerdem ist die Low-Level-Prozedur seit Beginn der vertikalen Aufzeichnung weitaus aufwendiger geworden, d.h. dort werden die Kandidaten gleich ordentlich gestreßt.

Gruß

Thomas
 
Dann sag ich mal vielen Dank für die zahlreichen Posts und die damit verbundene Hilfe^^.
 
Zurück
Oben