rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Ich habe hier einen ca. zehn Jahre alten Rechner, den ich vor ein paar Monaten außer Betrieb genommen habe. Das Schätzchen hat ein Gigabyte GA-EG45M-DS2H Mainboard mit einer Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz CPU und einer Samsung HD642JJ SATA-Festplatte. Kürzlich habe ich das mit einer Samsung SSD 860 EVO 1TB aufgerüstet und wieder in Betrieb genommen. Dann viel mir auf, dass btrfs scrub auf meiner 2.5"-USB-Backup-Platte nicht behebbare Fehler entdeckte. Komischerweise konnte ich die betreffende Datei trotzdem einwandfrei lesen. Normalerweise kommt in so einem Fall ein IO-Fehler. Weitere Durchläufe von btrfs scrub mit der USB-Platte an anderen USB-Ports fanden angeblich Fehler in anderen Dateien. Dann habe ich die Platte zwei Mal an einem anderen Rechner (der USB 3.0 unterstützt) geprüft, und dort wurden nie Fehler erkannt. Im Journal fanden sich dann haufenweise Blöcke mit Fehlermeldungen der verbauten Harddisk (also nicht der neuen SSD) - teilweise reihenweise im Zwei-Sekunden-Takt: Aug 10 11:29:04 babelfish kernel: ata3: SATA link down (SStatus 1 SControl 300)
Aug 10 11:29:04 babelfish kernel: ata3: EH complete
Aug 10 11:29:04 babelfish kernel: ata3: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
Aug 10 11:29:04 babelfish kernel: ata3: irq_stat 0x00000040, connection status changed
Aug 10 11:29:04 babelfish kernel: ata3: SError: { CommWake DevExch }
Aug 10 11:29:04 babelfish kernel: ata3: hard resetting link Mittlerweile habe ich diese Festplatte abgeklemmt und bei einem weiteren btrfs scrub wurden keine Fehler auf der USB-Platte gemeldet. Ich habe danach noch einmal einen Durchlauf an einem anderen USB-Port gestartet. Nach einer Stunde sind noch keine Fehler gemeldet worden. Ich werde das mal weiter laufen lassen und später sehen, ob es wieder Fehler gab. Kann es sein, dass die Festplatte defekt ist und den ganzen Betrieb auf dem Bus oder DMA stört, so dass auch das Lesen von der USB-Platte betroffen ist? Welche anderen Fehlerursachen könnte es noch geben? (Ich habe noch ein paar Ideen, will aber erst mal hören, was Euch in den Sinn kommt.) Danke!
|
rklm
Projektleitung
(Themenstarter)
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Zu früh gefreut: $ sudo btrfs scrub start -B /media/robert/Backup/
scrub done for 37affe7d-707c-4bd2-916d-e6ca33cfb768
scrub started at Fri Aug 23 06:56:21 2019 and finished after 04:58:32
total bytes scrubbed: 588.67GiB with 76 errors
error details: csum=76
corrected errors: 0, uncorrectable errors: 76, unverified errors: 0
ERROR: there are uncorrectable errors ☹ Im Moment neige ich zu der Theorie, dass das Mainboard einen Schuss hat. Vielleicht auch der Speicher. Was meint Ihr?
|
mrkramps
Anmeldungsdatum: 10. Oktober 2006
Beiträge: 5523
Wohnort: south central EL
|
Die Fehlermeldungen im Journal weisen auf Verbindungsabbrücke zwischen SATA-Controller und Festplatten-Controller hin, also eher ein Hardware-Problem. Normalerweise sollte in so einem Fall auch der UDMA CRC Error Count in den S.M.A.R.T.-Werten der betroffenen Festplatte hochgehen. Soweit ich dazu was im Internet finden konnte, reicht es ggf. schon mal die Steckverbindungen zu kontrollieren, den SATA-Port zu wechseln oder ein anderes Kabel zu nehmen. Aber wenn du die alte HDD vollständig (Strom und SATA) abgeklemmt hast und - sofern ich das richtig verstehe - eigentlich nur Daten von der SSD auf die USB-Festplatte überträgst, dann sollte das eigentlich tatsächlich keine Übertragungsfehler erzeugen, weil ob angeschlossen oder nicht die HDD sollte da gar nicht mit rein spielen. In diesem Kontext wäre jetzt meine erste Frage, ist die Festplatte mit den SATA-Verbindungsabrüchen an ATA3 wirklich die interne HDD oder deine externe USB-Festplatte? Passt das mit der Stromversorgung der USB-Festplatte?
|
rklm
Projektleitung
(Themenstarter)
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
mrkramps schrieb: Die Fehlermeldungen im Journal weisen auf Verbindungsabbrücke zwischen SATA-Controller und Festplatten-Controller hin, also eher ein Hardware-Problem.
Ja, so etwas in der Art habe ich auch vermutet.
Normalerweise sollte in so einem Fall auch der UDMA CRC Error Count in den S.M.A.R.T.-Werten der betroffenen Festplatte hochgehen. Soweit ich dazu was im Internet finden konnte, reicht es ggf. schon mal die Steckverbindungen zu kontrollieren, den SATA-Port zu wechseln oder ein anderes Kabel zu nehmen.
Werde ich bei Gelegenheit mal machen. Die Ausgangsfrage des Themas ist damit aber mit "nein" beantwortet. Von daher werde ich das im Moment erst mal nicht weiter verfolgen.
Aber wenn du die alte HDD vollständig (Strom und SATA) abgeklemmt hast und - sofern ich das richtig verstehe
Ja.
- eigentlich nur Daten von der SSD auf die USB-Festplatte überträgst, dann sollte das eigentlich tatsächlich keine Übertragungsfehler erzeugen, weil ob angeschlossen oder nicht die HDD sollte da gar nicht mit rein spielen.
Es werden nicht mal Daten von der SSD auf die USB-Platte übertragen: ich mache ja nur einen BTRFS Scrub. Dabei werden die Datenblöcke gelesen und mit den gespeicherten CRCs verglichen.
In diesem Kontext wäre jetzt meine erste Frage, ist die Festplatte mit den SATA-Verbindungsabrüchen an ATA3 wirklich die interne HDD oder deine externe USB-Festplatte?
Ist die interne HDD.
Passt das mit der Stromversorgung der USB-Festplatte?
Was meinst Du damit? Ich habe in den Specs keine Angaben dazu gefunden. Die USB-Platte bekommt Strom und läuft. Ob es sehr kurze Aussetzer zwischendurch gibt, kann ich nicht überprüfen, weil ich die geeigneten Werkzeuge (Spannungsschreiber) nicht habe.
Letztlich bleibt die Suche nach der Ursache für die angeblichen CRC-Fehler auf der USB-Platte. Soweit ich das sehe, können wir folgendes ausschließen: USB-Platte und -Kabel, da am anderen Rechner keine CRC-Fehler berichtet werden. Interne Verkabelung, da ich mehrere USB-Anschlüsse in dem Desktop versucht habe und dabei auch die rückseitigen auf der Platine (also ohne Verkabelung) waren.
Damit erscheint mir in absteigender Wahrscheinlichkeit der Fehler hier zu liegen: Mainboard Netzteil (weniger wahrscheinlich, weil ich da auch an anderer Stelle Effekte erwarten würde. Immerhin könnten verschiedene Baugruppen unterschiedlich auf Spannungsschwankungen reagieren.) Speicher (weniger wahrscheinlich, da Fehler hier auch an anderer Stelle Auswirkungen zeigen müssten) CPU (dito)
Wie seht Ihr das?
|
mrkramps
Anmeldungsdatum: 10. Oktober 2006
Beiträge: 5523
Wohnort: south central EL
|
Missverständnis meinerseits. War jetzt in Ermangelung von Erfahrung mit btrfs davon ausgegangen, dass du mit btrfs scrub festgestellt hättest, dass bei der Datenübertragung während des eigentlich Backups an einem Rechner Fehler aufgetreten wären und an dem anderen nicht. Dass du beim Scrubbing des identischen Datenbestands an einem Rechner unterschiedliche Fehler bekommst und an dem anderen gar keine, ist natürlich anders wenn auch ähnlich beunruhigend. Mainboard (USB-/SATA-Controller) ist - insbesondere unter Berücksichtigung der Fehler der internen HDD - kein verkehrter Ansatz. Arbeitsspeicher ließe sich mit memtest recht unkompliziert als Ursache ausschließen. Du könntest das Szenario noch mit einem anderen Datenträger testen. Den also mit btrfs formatieren, mit Daten vollpacken und an beiden Rechnern scrubben lassen. Wäre interessant, ob sich die fragwürdigen Ergebnisse reproduzieren lassen. Wäre sicherlich auch hilfreich, wenn du den betroffenen Datenbestand an weiteren Rechner testen könntest. Alles so Sachen, die ich dir aber wohl nicht extra erzählen muss 😉 Du hast als Betriebssystem Xubuntu 18.04 angegeben. Läuft das auf beiden Computern mit der gleichen Kernel-Version? Also nicht einer ggf. mit LTS-Kernel und einer mit HWE-Kernel? Nur für den Fall, dass es irgendeinen Bug/Regression/Änderung in btrfs gibt. Ansonsten fällt mir dazu auch nichts mehr ein.
|
rklm
Projektleitung
(Themenstarter)
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
mrkramps schrieb: [...] natürlich anders wenn auch ähnlich beunruhigend.
Genau.
Mainboard (USB-/SATA-Controller) ist - insbesondere unter Berücksichtigung der Fehler der internen HDD - kein verkehrter Ansatz. Arbeitsspeicher ließe sich mit memtest recht unkompliziert als Ursache ausschließen.
Gab es da mit Memtest nicht ein Problem mit 64 bit - oder war das nur bei UEFI-Rechnern? Muss ich mal nachschauen.
Du könntest das Szenario noch mit einem anderen Datenträger testen. Den also mit btrfs formatieren, mit Daten vollpacken und an beiden Rechnern scrubben lassen. Wäre interessant, ob sich die fragwürdigen Ergebnisse reproduzieren lassen.
Ja, da hast Du Recht. Ich muss mal schauen, aber ich habe gerade keine andere USB-Platte verfügbar. Vielleicht tut es ja auch ein USB-Stick.
Wäre sicherlich auch hilfreich, wenn du den betroffenen Datenbestand an weiteren Rechner testen könntest. Alles so Sachen, die ich dir aber wohl nicht extra erzählen muss 😉
Ja, das könnte ich natürlich auch noch machen. Wobei ich dazu neige, das für eher überflüssig zu halten, denn wie sollte ein Fehler in einem System aussehen, das keine CRC-Fehler findet? So einen Zufall gibt es eher nicht.
Du hast als Betriebssystem Xubuntu 18.04 angegeben. Läuft das auf beiden Computern mit der gleichen Kernel-Version? Also nicht einer ggf. mit LTS-Kernel und einer mit HWE-Kernel? Nur für den Fall, dass es irgendeinen Bug/Regression/Änderung in btrfs gibt.
Ja, beide mit normalen Kerneln und apt dist-upgrade aktuell.
Ansonsten fällt mir dazu auch nichts mehr ein.
Mir ist noch eingefallen: als kostengünstige und wenig aufwändige Alternative zum Boardwechsel könnte ich ja einfach mal einen USB-Kontroller wie diesen einsetzen. Möglicherweise ist ja nur der USB-Teil der South Bridge im Eimer.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
rklm schrieb: Gab es da mit Memtest nicht ein Problem mit 64 bit - oder war das nur bei UEFI-Rechnern? Muss ich mal nachschauen.
Laut memtest (Abschnitt „EFI-Bootmanagement“) bekommt man mit UEFI keinen Eintrag im Bootmenü von Grub, aber man kann das ohne weiteres von einem Live-Medium starten.
|
rklm
Projektleitung
(Themenstarter)
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Memtest war nach über 12 Stunde und 70% von Pass 3 unauffällig. Ich habe noch eine Idee...
|
rklm
Projektleitung
(Themenstarter)
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
rklm schrieb: Ich habe noch eine Idee...
..., die leider nicht aufging: ich habe die USB-Platte noch einmal an dem anderen Rechner an einem Nicht-USB-3-Port gescrubbed, weil es ja sein könnte, dass die Plattenelektronik mit USB 3 kein Problem hat, aber mit USB 1 und 2 sehr wohl. Aber auch da kein Fehler. Werde mir jetzt einen USB-Controller besorgen und damit testen.
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Ich bin nicht sicher ob ich alles richtig interpretiert habe. Aber ich vermute mal, dass die USB Platte auch über USB mit Strom versorgt wird. Bei einem so komplexen Fehlerbild wäre die Stromversorgung mein Hauptverdächtiger. Ich habe da schon die merkwürdigsten Dinge erlebt wo z.B. langsam und schleichend einzelne Spannungen weich wurden, was sich zuerst nur beim Start bemerkbar machte. Aber das ich Stromversorgungen nicht einmal so weit traue, wie ich sie werfen kann, hatte ich ja schon mal angedeutet.
|
rklm
Projektleitung
(Themenstarter)
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
rklm schrieb:
Werde mir jetzt einen USB-Controller besorgen und damit testen.
Ist jetzt passiert. Ich habe zwei Durchläufe mit btrfs scrub gemacht und siehe da: scrub done for 37affe7d-707c-4bd2-916d-e6ca33cfb768
scrub started at Thu Sep 5 18:24:47 2019 and finished after 01:29:33
total bytes scrubbed: 588.68GiB with 0 errors Hurra! Bleibt als Erklärung nur, dass entweder die Plattenelektronik nicht gut mit langsameren USB-Standards zurecht kommt oder die South Bridge einen so speziellen Fehler hat, das nur USB-Geräte davon betroffen sind. Die SATA-SSD funktioniert ja. Seltsam. Aber ich denke, wir können das Thema mal als gelöst markieren.
|