Am Fri, 09 Jan 2015 17:57:59 +0100 schrieb Alexander Thuermer
Ein Abbrechen des Kopiervorganges führt noch ca. weitere 1-2 Minuten zu 70 - 80% cpu wait.
Bei mir treten nach solchen Vorgängen sporadisch auch UDMA CRC Fehler auf, muss aber nicht direkt damit zusammen hängen.
Der Effekt ist vorhanden bei - Festplatte zu USB-Stick - aber auch Festplatte zu zweiter Festplatte (hier S-ATA zu P-ATA)! - USB Stick zu zweitem USB Stick bremst spürbar das Reaktionsverhalten des Systems aus.
Die CRC-Fehler weisen m.E. am ehesten in die richtige Richtung. Offenbar hat der Kernel Probleme beim Massenspeicherzugriff, was am ehesten irgendwo zwischen Memory und Massenspeicher-IO seine Ursache hat - Treiber/Kernel-Module inklusive. Den "Nachlauf" würde ich darauf zurückführen, dass im Hintergrund aus dem write-behind cache auf den Massenspeicher weitergeschrieben wird. Performance-Probleme beim IO sieht man recht gut in "top", wenn man mit "i" die verzögerten Prozesse ansieht. Normalerweise sieht man kaum Prozesse mit running-state (S) "D", bei Überlast schon. Abgesehen von schleichenden Festplattendefekten (bei USB-Sticks unwahrscheinlich... ;) ) taucht das bei mir hauptsächlich bei defekten Hostadaptern, ihren Verbindungen oder bei Übertemperaturen einzelner Komponenten auf. Das kann die Festplatte sein, aber auch eine schlecht montierte CPU heizt mitunter schnell auf und drosselt sich dann selbst. Also neben allgemeiner Beobachtung des Kernel-Log auch die Temperaturmonitore aktivieren (SMART für Festplatte, lm_sensors für Mainboard und CPU). Ich habe hier zum Beispiel ein System, bei dem zwei am IDE-Hostadapter angeschlossenen Platten eine zunehmende Zahl von CRC-Fehlern liefern, wenn sie zu heiß werden. Irgendwann werden sie dann ganz abgeklemmt, aber bis dahin stockt das System immer mehr durch retries. Den Grund in einer neueren Kernel-Version zu suchen, würde ich zunächst vermeiden, weil man da schnell im Wald landet. Tatsächlich sind von einer OS-Version zur nächsten viele Parameter geändert. Neue Applikationen, neue Konzepte oder ganz schlicht höhere Last durch zusätzliche Standardprozesse machen Fehlereingrenzung via Vergleich zu komplex. Oder die Hardware hatte vorher schon eine Macke, die nur zufällig nicht zum Tragen kam. Du solltest das auch mal mit genaueren Daten unterfüttern. Welche Datentransferraten erreicht das System bei welchen Kopiervorgängen? Welches USB-device, welche USB-Version? Welche Hardware? Bremst es auch beim Nur-Lesen oder Nur-Schreiben (Test mit dd von /dev/zero oder dd nach /dev/null !) auf die verschiedenen devices. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org