Mainboard defekt?

[ultrablau]

Hallo,

vielleicht kann mir jemand mit meinem Problem bei Backups mit rsync helfen, von dem ich denke, dass es auf ein Hardwareproblem (vermutlich teilweise defektes Mainboard) verweist.

Mein Betriebssystem ist eine Standardinstallation von Debian 8/Jessie.
Das Mainboard ist ein Asus P5KPL-AM.

Mein Backup mit rsync mache ich normalerweise so, dass ich eine USB-Festplatte anschließe, mounte, dann zum Einhängepunkt der Platte gehe und dort folgenden Befehl ausführe:

Code: Alles auswählen

rsync -av --delete-after /home/user .

rsync beginnt dann sofort damit, alle neuen oder veränderten Dateien zu übertragen, die direkt in /home/user liegen, also nicht in Unterordnern. Danach bleibt die Übertragung kurz stehen, wobei wahrscheinlich die Dateien in den Unterordnern gelesen und nach Änderungsdatum verglichen werden, dann wird der Rest synchronisiert.

Seit einiger Zeit ist es nun so, dass diese kurze Pause in der Datenübertragung erheblich länger dauert als üblich, nämlich ca. 6 Minuten. Dananch geht das Backup normal vonstatten.

Ich hatte das Problem kürzlich mal mit jemandem im IRC kurz besprochen, der meinte, ich solle mir mal die Ausgabe von atop ansehen, während das Backup läuft, um das Problem zu lokalisieren. Das habe ich getan und bin dabei darauf gestoßen, dass die Auslastung der Platten während des Backupprozesses immer wieder die 100%-Marke überschreitet, was mir einigermaßen paradox erscheint.

Zwei Besipiele:

Backup auf Toshiba MQ01UBD100, USB 3.0 (sdc):

Code: Alles auswählen

DSK |           sdc  |  busy    116% |  read       4  |  write   2751  |  KiB/w    116  |  MBr/s   0.00 |  MBw/s  31.27  |  avio 3.63 ms  |
DSK |           sda  |  busy     19% |  read    2458  |  write      0  |  KiB/w      0  |  MBr/s  30.71 |  MBw/s   0.00  |  avio 0.66 ms  |

Backup auf Intenso Memory Case, USB 3.0 (sdc):

Code: Alles auswählen

DSK |          sdc | busy    108% | read       4 | write   2329 | avio 4.29 ms |

Es gibt auch ab und an das Problem, dass die USB-Platten nicht erkannt werden, d. h. in meinem Dateimanager nicht als mountbare Dateisysteme auftauchen. Dieses Problem bestand auch schon mit USB-Sticks an den Frontadaptern des Gehäuses, die ich mittlerweise abgesteckt habe. Bei der Toshiba-Platte bricht zudem auch ab und an die Stromversorgung zusammen. Außerdem wird mein USB-WLAN-Adapter fast nie beim Hochfahren durch das System automatisch mit dem Netzwerk verbunden (was aber so sein sollte), weswegen ich mich fast immer per nachträglichem ifup wlan0 verbinden muss. Auch kann ich seit einiger Zeit nichts mehr über meinen HP Lasterjet drucken, der per USB mit dem Rechner verbunden wird. Am Laptop eines Bekannten funktioniert der Drucker aber einwandfrei.

Ich hatte nun den Verdacht, dass es sich um ein Problem mit dem USB-Controller handelt. Deshalb habe ich eine zweite SATA-Platte eingebaut, um mein Backup darauf zu machen. Interessanterweise zeigte die Beobachtung des Backupprozesses mit atop hier ein ähnliches Ergebnis:

Code: Alles auswählen

DSK |           sdb  |  busy    105% |  read       5  |  write   1134  |  KiB/w    497  |  MBr/s   0.00 |  MBw/s  55.14  |  avio 8.78 ms  |
DSK |           sda  |  busy     92% |  read    4488  |  write      0  |  KiB/w      0  |  MBr/s  56.06 |  MBw/s   0.00  |  avio 1.96 ms  |

Und auch hier muss ich ca. 3½ Minuten warten, bevor rsync mit der Synchronisation der Daten aus den Unterordnern des Benutzerverzeichnisses beginnt, was gefühlt immer noch erheblich länger ist, als sonst der Fall war.

Ich habe auch bereits einmal alle anderen USB-Geräte bis auf die jeweilige Backup-Platte abgesteckt, wobei sich nichts verändert hat. Außerdem habe ich vor ein paar Tagen auf Verdacht einen ca. 8-stündigen RAM-Test gemacht, bei dem es keine Fehlermeldungen gab. Die Festplatte wurde gestern mit SMART geprüft, wobei keine Fehler gefunden wurden. Am Netzteil liegt das Problem wahrscheinlich auch nicht, denn das ist erst ca. ein halbes Jahr alt.

Es sieht also aus, als sollte ich das Mainboard austauschen. Was meint ihr? Und wie kommen diese Werte bei atop möglicherweise zustande?

[hikaru]

Das Mainboard ist ja nun schon etwas älter (2007?). Von daher könnte es durchaus sein, dass es langsam Ausfallerscheinungen zeigt.
Allerdings hatte ich kürzlich auf einem P5K/EPU (2008) ähnliche Symptome (sporadisch nicht erkannte SATA-Geräte, Probleme beim Erkennen des internen USB-Cardreaders oder des Druckers, abnehmende Stabilität der übertakteten CPU).
Zunächst hatte ich den USB-Controller in Verdacht, denn mit angeschlossenem Drucker und/oder Cardreader startete der Rechner teilweise nicht mal. Vor einem Monat habe ich das Netzteil ausgetauscht, als selbst ohne USB-Geräte der Rechner nur noch sporadisch startete. Ich möchte noch kein abschließendes Urteil abgeben, aber seitdem läuft der Rechner wieder stabil. Das alte Netzteil war mit 500W auf jeden Fall ausreichend dimensioniert und stammte von einem namhaften Hersteller.

Was die "busy"-Angabe von atop aussagt weiß ich nicht, aber die 30MB/s die dabei stehen lasten weder die HDDs, noch den SATA-Controller (selbst im Duplex) aus.
Spontan hätte ich vermutet, dass das eine CPU-Last-Anzeige ist. Dann wären zumindest Werte über 100% erklärbar. Allerdings müsste dann eine für den LGA 775 sehr schwache CPU verbaut sein, um die CPU-Last bei einem rsync-Job mit 30MB/s zu erklären. Selbst bei einem Atom N475 habe ich schon über das im Vergleich zu SATA eher ineffiziente USB-3.0-Protokoll die doppelte Übertragungsrate gesehen.

[rendegast]

Ist Dir vielleicht mal ein Skript danebengegangen,
welches Millionen? von 0-Byte-Dateien angelegt hat, vielleicht im Hintergrund?

Irgendwelche rekursiven Mounts?
Oder auf ein ISO o.ä., welches eine Symlink-Bombe darstellt.

Code: Alles auswählen

date
find /home/user | sort | wc -l
date

date
find /mountpoint | sort | wc -l
date

Dateisystem des Datenträgers?


Wegen Hardwarefehlern
'dmesg' ?

[ultrablau]

Hallo,

danke für die Hinweise.

Das Baujahr des Mainboards konnte ich nicht herausfinden. Das BIOS ist jedenfalls von 2009. Die CPU ist eine Pentium Dual-Core E5300 mit je 2.60GHz. Der Rechner läuft durchschnittlich etwa 5 Stunden pro Tag.

Der Dateisystemtyp meiner /home-Partition ist ext4. Die Backupplatten sind mit ext3 formatiert. Was die Anzahl der Dateien im Vergleich angeht, sieht das Ergebnis so aus:

Die /home-Partition:

Code: Alles auswählen

date
Do 22. Sep 16:47:26 CEST 2016

find /home/user | sort | wc -l
167049

date
Do 22. Sep 16:48:11 CEST 2016

Die interne Backupplatte:

Code: Alles auswählen

date
Do 22. Sep 16:49:07 CEST 2016

find /mnt | sort | wc -l
167022

date
Do 22. Sep 16:49:48 CEST 2016

Eine der externen Backupplatten (Toshiba MQ01UBD100):

Code: Alles auswählen

date
Do 22. Sep 16:52:08 CEST 2016

find /media/user/backup | sort | wc -l
167021

date
Do 22. Sep 16:52:50 CEST 2016 

Das ist also offenbar in Ordnung.

Irgendwelche rekursiven Mounts?
Oder auf ein ISO o.ä., welches eine Symlink-Bombe darstellt.

Soweit ich sehe, nichts dergleichen.

Die ausgabe von dmesg gibt's hier:
39511

[MSfree]

Die Festplatte, auf der sich deine Quelldaten befinden, kannst du als Fehlerursache ausschließen?

[ultrablau]

Die Festplatte, auf der sich deine Quelldaten befinden, kannst du als Fehlerursache ausschließen?

Die Festplatte wurde gestern mit SMART geprüft, wobei keine Fehler gefunden wurden.

Allerdings habe ich mir nun nach einem der üblichen stillen Zusammenbrüche meiner WLAN-Verbindung noch einmal die Ausgabe von dmesg angesehen, wobei sich doch eine erhebliche Anzahl Fehlermeldungen gefunden hat: 39512.

[MSfree]

Allerdings habe ich mir nun nach einem der üblichen stillen Zusammenbrüche meiner WLAN-Verbindung noch einmal die Ausgabe von dmesg angesehen, wobei sich doch eine erhebliche Anzahl Fehlermeldungen gefunden hat: 39512.

Naja, die Fehler beziehen sich aber wohl nur auf den WLAN-Adapter.

Und, meine persönliche Meiung zu SMART bei Festplatten ist, daß ich den Ausgaben keinen Meter weit traue. Meiner Erfahrung nach ist SMART nicht brauchbar für die Fehlerdiagnose und auch nicht zur Vorhersage von demnächst auftretenden Fehlern.

Du solltest mal die Ausgabe von journalctl nach Fehlern durchsuchen.

[ultrablau]

Naja, die Fehler beziehen sich aber wohl nur auf den WLAN-Adapter.

Genau. Ich hatte das angehangen, weil es meinen Verdacht auf ein USB-Problem bestätigt.

Ich bekomme auch bezüglich meiner USB-Soundkarte bei Hochfahren immer die Fehlermeldung:

Code: Alles auswählen

usb 1-1: string descriptor 0 malformed (err = -61), defaulting to 0x0409

Ob das allerdings am Mainboard oder an der Soundkarte liegt, kann ich nicht sagen. Das gilt auch für den WLAN-Adapter. Ich werde mal auf einem Testrechner Debian Jessie aufsetzen und schauen, wie es sich da verhält.

Ich habe nun noch testweise ein Backup auf eine USB-2.0-Platte mit externer Stromversorgung gemacht, auf der zufällig ein älteres Backup meines /home-Verzeichnisses lag. Im Grunde gab es das gleiche Ergebnis wie sonst, nur dass die Wartezeit eine Minute weniger betragen hat. Das liegt aber möglicherweise daran, dass der Stand des Backups auf der USB-Platte älter war, als bei den Platten, die ich regelmäßig für Backups benutze.

Und, meine persönliche Meiung zu SMART bei Festplatten ist, daß ich den Ausgaben keinen Meter weit traue. Meiner Erfahrung nach ist SMART nicht brauchbar für die Fehlerdiagnose und auch nicht zur Vorhersage von demnächst auftretenden Fehlern.

Du solltest mal die Ausgabe von journalctl nach Fehlern durchsuchen.

Ok, die Ausgabe von journalctl habe ich hier abgelegt: 39516
Fehlermeldungen zur Festplatte finden sich da aber, so weit ich sehe, nicht.