Tobias Crefeld schrieb am 09.01.2015 um 19:23:
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. Ja nehme ich auch an - nur keine Idee Den "Nachlauf" würde ich darauf zurückführen, dass im Hintergrund aus dem write-behind cache auf den Massenspeicher weitergeschrieben wird. Wahrscheinlich ja - da die Schreibrate parallel ja gering wird, dauert das "Flushen" natürlich auch länger 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. mit "i" zeigt plasma-desktop, kio_file,kworker /u8:1, kworker /0:2,konsole 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. [...] Hardware kann ausgeschlossen werden; da selbes Szenario nochmal unter Opensuse 11.4 (evergreen, die war bis vor 2 Monaten meine Arbeitsversion) getestet und alles im erwarteten Bereich. Gerade nochmal getestet.
P.S: Platten sind via smartctl inkl. selftest beide ok
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. Kernel oder Module habe ich im Verdacht, aber stehe wie Du sagtest eher im Wald; eventuell hat sich für eine spezifische Komponente bei mir der Kernel-Treiber geändert oder so etwas. Specs s.u. 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. Intel Core2 Duo 3GHz, 8 GB RAM, WD Enterprise 2TByte, WD Caviar 320 GByte MSI P6N SLI mit nForce 650i d.h. USB 2.0 Sticks: Transcend 32 GB u.a. alle USB 2.0
Schreibraten kopieren in Dolphin bei Disk2Disk: 11.4 konstant ~50 MB/s 13.1 erst 118 MB/s dann nach 30Sek ca. 18 MB/s Wie gesagt HW Defekt scheidet aus da es unter OS 11.4 geht. Falls der Fehler bei niemandem anderen auftritt ist es dann eher die HW Config von mir und ich untersuche und google hier selbst weiter. Falls das jedoch bei einem Test auch bei anderen auftritt, dann ist das ein Problem in der Distri (es gab ja schon mal von jemanden einen bugreport). Dann würde ich einen Bugreport aufmachen. Deshalb hier nachgefragt vielen Dank Alexander -- 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