SATA Übertragungsfehler

[wawi]

Hallo,

bekanntlich garantiert eine Paranoia nicht, dass sie nicht trotzdem hinter einem her sind...

Auch mein seit Jahren üblicher paranoider Vergleichslauf nach dem wöchentlichen Klonen der Festplatten bringt neuerdings immer wieder Fehler, obwohl der Kopiervorgang scheinbar störungsfrei und ohne Log-Eintrag abläuft und der Rechner insgesamt unauffällig arbeitet.

Ich starte auf einem separaten System (entweder Puppy vom USB-Stick oder Q4OS von einer dritten Platte) ein script in der Art:

dd if=/dev/sdb of=/dev/sdc bs=4096
cmp /dev/sdb /dev/sdc

Die Fehler treten an verschiedenen SATA-Ports und mit verschieden Platten auf. Die betreffenden Platten lassen sich in einem bereits ausgemusterten und testweise reaktivierten Rechner fehlerlos klonen. Ich habe nun ein neues Motherboard bestellt. Das mangelhafte ist ein GA-78LMT-USB3.

Hat jemand schon ähnliches erlebt, also Übertragungsfehler ohne Logeinträge und ohne Abbruch? Eigentlich sollte es das nicht geben, denn zumindest SATA ist mit CRC abgesichert. Aber das gilt dann wohl nicht für internen Verbindungen auf dem Board.

 

[owned_you]

Sata Kabel schon mal getauscht?

 

[mkossmann]

Ein Speichertest (z.B. memtest86) läuft auch ohne Fehler durch ?

 

[Hanne]

IM BIOS

Turbo CPB (Note) [Disabled] so eingestellt ? (STANDARD-Einstellung)

 

[inge70]

was für Fehler sind das denn eigentlich, die da erscheinen?

 

[h00bi]

Schau mal auf die Smart Werte der Datenträger, dort werden CRC Fehler protokolliert.
Zudem kann der Fehler auch im RAM passieren, daher hier auch nochmal testen.

 

[wawi]

Danke für die zahlreichen Anregungen zur Fehlersuche. Der Treffer war der Speichertest, daran hatte ich nicht gedacht. Es zeigten sich Fehler, die nach Entfernen eines Riegels verschwanden. Ich gehe davon aus, das damit der Ursprungsfehler auch weg ist. EDIT: Fehler ist weg.

Zu den anderen Kommentaren:

SATA-Kabel wurden verschiedene verwendet, weil ich die Platten in verschiedenen Wechseleinschüben hatte. Vor allem aber sollte ein Fehler im Kabel ja eigentlich gemeldet werden, einen Log-Eintrag bewirken oder wenigsten einen Abbruch, nicht wahr?

Turbo CPB - irgend eine Tuning-Einstellung? So etwas lasse ich auf Standard.

Die Art der Fehler ist einfach eine Nicht-Übereinstimmung von Quell- mit Zielplatte, vermutlich nur bei wenigen Bytes. cmp bricht ab, wenn es die ersten Unterschied findet und der test mit md5sum gibt andere Prüfsummen.

SMART-Werte waren sauber. Kein Wunder, die Platten waren ja auch in Ordnung, wenn der RAM die Fehlerursache war. Ich werde künftig den RAM regelmäßig testen.

Der Fehler beweist, wie sinnvoll es ist, bei größeren Kopieraktionen eine Überprüfung folgen zu lassen, zumal wenn man das im Script automatisieren kann. Mag sein, dass ECC-RAM im konkreten Fall auch geholfen hätte, aber es gibt ja sicher weitere Fehlermöglichkeiten im internen Datenstrom.

 

[Holt]

Korrupte Dateien sind ein typisches Zeichen für RAM Fehler, Ultra-DMA CRC Fehler führen dagegen nicht einfach zu korrupten Dateien, da die Übertragungen ja wiederholt werden und nur wenn es trotz zahlloser Übertragungen dann nicht möglich ist die Daten fehlerfrei (also mit korrekter CRC32 hinter dem FIS) zu übertragen, dann wird die Übertragung irgendwann abgebrochen, aber mit einer Fehlermeldung.

Ein System mit ECC RAM welches diese Funktion auch unterstützt hätte hier die Probleme mit Sicherheit vermieden, wenn es korrekt konfuguriert ist, also auch bzgl. der Reaktion auch nicht korrigierbare RAM Fehler.

 

[wawi]

Ein System mit ECC RAM welches diese Funktion auch unterstützt hätte hier die Probleme mit Sicherheit vermieden, wenn es korrekt konfuguriert ist, also auch bzgl. der Reaktion auch nicht korrigierbare RAM Fehler.

ECC RAM hatte ich bei der Zusammenstellung eines Vorgänger-PC erwogen, denn Datenintegrität ist mir sehr wichtig. Ich fand dann aber keine klare Aussagen darüber, ob und wie es vom Mainboard und vom Betriebssystem (hier Linux) unterstützt wird und habe es gelassen.

Gibt es dafür inzwischen eine Auswahl bezahlbarer Mainboards?

Wo und wie konfiguriert man eine übliche Linux-Distribution (hier z.Zt. das Debian-Derivat Q4OS) so, dass korrigierbare Fehler gemeldet und bei nicht korrigierbaren Fehlern gestoppt wird?

Oder stoppt man lieber nicht, damit man wenigstens noch die Meldung lesen kann?

 

[Holt]

Das Betriebssystem muss es nicht unterstützen, solange es nur um die Fehlerkorrektur geht, dies ist eine reine HW Funktion. Erst wenn es um die Reaktion auf unkorrigierbare Fehler oder das Auslesen von Statistiken wie etwa die Anzahl der korrigierten Bitfehler geht, ist die Unterstützung durch das OS nötig. Wenn man mehr Wert auf Datenintegrität legt als die Mehrzahl der Heimanwender, dann kommt man um ECC RAM (und das passende Boards und CPU die dies auch unterstützen, sonst hängen die zusätzlichen Bits nur nutzlos in der Luft) nicht herum.

Nicht korrigierbare Fehler sind übrigens sehr selten, daher sollte man sich nicht vom Einsatz von ECC RAM abhalten lassen, nur weil man nicht sicher ist was wie das System dann darauf reagieren soll.

 

[wawi]

Demnach muss ECC ggf. im BIOS aktiviert werden.

Unkorrigierbare Fehler mögen selten sein, aber spätestens wenn der RAM kaputt ist, treten sie auf. Dann möchte man eine Warnung. Wie konfiguriert man das unter Linux?