Banned
Admiral
- Registriert
- Sep. 2014
- Beiträge
- 9.757
Maitry schrieb:
Ja, es ist in der Tat komplex, wobei das Datenkabel nicht dazu führen sollte, da Laufwerke den Transfer eigentlich über CRC absichern und bei nicht erfolgreichem Transfer erneut probiert wird. Die Laufwerke sollten dann idR bei den Smart-Werten beim Attribut "UltraDMA CRC" einen hohen Rohrwert aufweisen, wenn es Probleme mit dem Kabel gibt. Ist das nicht der Fall, ist das eher nicht die Ursache. Hier allerdings der Hinweis, da es sich um USB-Platten handelt: Ich weiß nicht, wie es zwischen USB Controller und SATA aussieht. Hier kann man keinen Log einsehen vom Controller, weshalb es theoretisch möglich wäre, schätze ich.
Hier mein Ratschlag: Verwende eine Software (z.B. ein Backup-Programm), die den Transfer überprüft, also einen Abgleich zwischen Ziel und Quelle vornimmt.
- Zum RAM:
Hier sollte auf jeden Fall (z.B. mit Memtest) der RAM auf Defekt geprüft werden. Nichts ist so übel wie ein defekter RAM, der nach und nach lange Zeit unbemerkt Daten korrumpiert.
Wenn man bei RAM von Bitflips spricht, dann meint man damit Bits, die im RAM oder zwischen RAM und CPU kippen. ECC sichert sowohl im RAM als auch auf dem Weg von und zu diesem gegen 1-Bit-Fehler ab und kann Multi-Bit-Fehler bis zu einer gewissen Anzahl erkennen (on-die-ECC wie bei Standard DDR5 nur im RAM selbst).
Das Problem hier ist generell, dass Fehler, die nicht korrigiert werden konnten, eben als fehlerhafte Daten auf dem Datenträger landen und dann helfen da die Prüfmechanismen für den Datenträger logischerweise auch nicht mehr. Allerdings sind 1-Bit-Fehler schon sehr selten und Multi-Bit-Fehler extrem selten. Ein 1-Bit-Fehler wird dir z.B. normalerweise keine Videodatei oder MP3 verhunzen; bei einer Bilddatei ist es schon deutlich wahrscheinlicher, aber immer noch kein riesiges Risiko (es ist eben deutlich wahrscheinlicher, dass einfach ein Pixel nicht mehr stimmt, als dass an der ganzen Struktur was beschädigt wird). Trotzdem will man sowas natürlich vermeiden.
Maitry schrieb:
Das ist doch eigentlich schon mal ein guter Ansatz.
Maitry schrieb:
Du kannst gerne nachschauen, bis zu wie vielen fehlerhaften Bits der ECC korrigieren kann (ich weiß es gerade nicht aus dem Kopf
). Er hat eben wie jeder ECC bzw. jeder Fehlerkorrekturmechanismus seine Grenzen. Im schlimmsten Fall ist es sogar möglich, dass so viele Bits kippen, dass es nicht mal mehr vom Prüfverfahren erkannt wird (das ist z.B. bei CRC32 natürlich wahrscheinlicher als bei SHA256 - sollte einleuchten).Je länger ein Datenträger nicht geprüft wird, desto wahrscheinlicher ist es, dass sich Bitfehler mit der Zeit kumulieren und dann eben zu Fehlerbildern führen, die nicht mehr korrigiert und im schlimmsten Fall nicht mal mehr erkannt werden können (die Prüfsumme kann natürlich ebenfalls korrumpiert werden und damit auch zu einem zu unrecht als fehlerhaft erkannten Block führen).
Ergänzung ()
Evil E-Lex schrieb:
Müsste dann wahrscheinlich ein Problem mit dem Controller des Gehäuses sein, denn ansonsten wird ja über SATA eigentlich geprüft (UltraDMA CRC). Ich würde auch eher davon ausgehen, dass es bei ihm nicht an Bitrot liegt, denn wenn er die Daten regelmäßig mit chkdsk /r prüft, da müsste er schon sehr Pech haben, dass mehrere Dateien korrumpiert sind, sofern das Laufwerk keinen Defekt aufweist.
Zuletzt bearbeitet:
