Banned schrieb:
Bei den error-correcting codes gibt es einen Bereich, in dem korrigiert wird, und einen, indem ein Fehler gemeldet wird. M.W. sind die Bereiche, in denen korrigiert wird, sehr klein im Vergleich zu denen, in denen ein Fehler gemeldet wird, eben um zu vermeiden, dass die Platte falsche Daten liefert. Hier ist z.B. eine ST2000VX008-2E3164, bei der melder SMART:
Code:
1 Raw_Read_Error_Rate 0x000f 113 099 006 Pre-fail Always - 51825616
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0Die Platte hat also offenbar 51 Millionen Faelle, in denen sie einen Sektor fehlerhaft gelesen hat (im Durchschnitt fast 1000 Faelle pro Betriebsstunde). Das hat sie dann offenbar lieber erkannt statt es falsch zu korrigieren, und hat den Sektor dann wohl noch einmal und diesmal erfolgreich gelesen, und deswegen den Sektor auch nicht reallokiert.
Wie sollte das etwas nutzen? Wenn z.B. der SATA-Controller einer Maschine gelegentlich Bits kippt, und Du das auf eine andere Maschine mit rsync hinueberkopierst, wird rsync die Pruefsumme von den schon gekippten Bits berechnen, und die wird daher auf der anderen Maschine als korrekt ausgewiesen werden, obwohl die Daten kaputt sind.
Genau. Die HDD irgendwo zwischen dem Fehlerkorrigieren der ausgelesenen Daten und dem Hinzufuegen des CRC beim versenden (habe ich so aber noch nicht erlebt), oder der Host-Adapter, oder die Uebertragung vom Host-Adapter zum Speicher (das habe ich schon erlebt). Oder was auch immer. Die Pruefsummen im Dateisystem sind eine End-to-End-Ueberpruefung, die solche ansonsten ungesicherten Teile des Uebertragungswegs mit absichert.
In einem Fall, in dem Fehler auftraten, war sogar ECC-RAM im Computer. Das hilft halt nur gegen einen weiteren Abschnitt.
Vermeiden laesst es sich nicht (wenn man nicht in Richtung voll redundanter Hardware geht), erkennen aber schon, und dadurch vermeiden, dass es ein grosses Problem wird. Defektes RAM hatten wir auch schon einmal, da haben wir dank ECC gemerkt, wo das Problem lag und haben es eliminiert. Auf der Maschine haben wir uebrigens ZFS als File System, das hat aber keinen Fehler gemeldet. Es gab ohnehin nur einen korrigierbaren (und korrigierten) Fehler, und der trat offenbar nicht in einem der Puffer auf, in denen ZFS seine Ueberpruefungen vornimmt.
P.S.: Das steckt auch hinter der Empfehlung von ECC fuer ZFS. Nicht dass ZFS nicht auch ohne ECC gehen wuerde, aber ZFS sichert den Uebertragungsweg von den Schreibpuffern des Betriebssystems (im RAM) zur Platte/SSD und zurueck wieder bis zu den Lesepuffern des Betriebssystems. Wenn man dann ECC hat, ist der weitere Weg gesichert, wenn nicht, nicht.
Zuletzt bearbeitet:
) Sollte mir da evtl. mal ne Festplatte für kaufen
