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

Allen nochmals vielen Dank - hat sich weitgehend geklärt: 1) der hohe IO-wait ist wohl normal da die neueren Kernel,speziell der Desktop Kernel von OS 13.1 erst einmal sehr intensiv den RAM Cache füllen und dann die Festplatte nicht hinterherkommt. -> habe den "default" Kernel installiert, da ist das Caching gemäßigter und ähnlich Opensuse 11.4 2) Die UDMA CRC Fehler [2], die ich unter dem selbem Test in 13.1 bekomme und zuverlässig NICHT unter 11.4 evergreen geht wohl auf Probleme mit neueren Kernel Versionen mind. ab 3.11 und den Treibern für ÄLTERE SATA Controllern zurück. Da scheint es einen noch ungefundenen Bug zu geben, der bei starkem Lesen oder Schreiben mit NCQ aktiviert bei SATA Controllern im "IDE Modus" (nicht AHCI) UDMA Fehler produziert [2]. Opensuse 11.4 evergreen mit älterem Kernel 3.0 ist davon wohl nicht betroffen und daher kann ich das dort auch nicht reproduzieren (mit NCQ aktiviert). Abhilfe schafft bei manchen Konstellationen NCQ per echo 1 > /sys/block/sdb/device/queue_depth zu deaktivieren. Hat zumindestens heute bisher beim Testen keine UDMA CRC errors geworfen. Werde das genauer beobachten und schauen ob es schon einen Bugreport bei Opensuse gibt. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1084928 https://bugzilla.kernel.org/show_bug.cgi?id=89261 http://www.itechlounge.net/2013/07/linux-ata-failed-command-read-fpdma-queue... [2] Fehler Meldungen bei mir: 2015-01-11T21:19:36.238411+01:00 linux-os131b64 kernel: [14936.666817] ata3.00: failed command: WRITE FPDMA QUEUED 2015-01-11T21:19:36.238411+01:00 linux-os131b64 kernel: [14936.666821] ata3.00: cmd 61/00:90:00:7c:78/04:00:2b:00:00/40 tag 18 ncq 524288 out 2015-01-11T21:19:36.238412+01:00 linux-os131b64 kernel: [14936.666821] res 41/84:60:80:f6:77/84:00:2b:00:00/40 Emask 0x10 (ATA bus error) 2015-01-11T21:19:36.238413+01:00 linux-os131b64 kernel: [14936.666822] ata3.00: status: { DRDY ERR } 2015-01-11T21:19:36.238414+01:00 linux-os131b64 kernel: [14936.666824] ata3.00: error: { ICRC ABRT } -- 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

Lutz Nülle schrieb am 09.01.2015 um 20:03:

Alexander Thuermer schrieb:

...

Hallo Liste,

mir ist Folgendes aufgefallen, und ich würde mich freuen wenn das auch noch jemand testen kann bevor ich einen Bugreport aufmache.

Problem: Kopieren großer Dateien führt zu (zu) hoher CPU Last

Positiv getestet mit: Opensuse 13.1 (32 und 64 Bit) / 13.2 (64 Bit) Negativ getestet mit: OS 11.4 evergreen (32 Bit)

Um die Sache mal einzugrenzen: ich hab mal den Test gemacht

OS 13.1-32 - 4 GB mit 5 HDs (Dateisysteme ext4, xfs, ntfs über usb)

a) eine 4,7GB-Iso über smb von Win-Client auf internes ext4-LW konstante CPU-Last - Einbrüche gab es nur kurz wenn der Client nicht liefern konnte) b) auf os-Rechner von ext4-HD auf xfs-Laufwerk mit mc konstante CPU-last c) von ext4-HD auf USB-Platte per usb2 konstante CPU-Last.

alles normal ..

Auch das könnte auf ein Hardware-Problem hinweisen

Danke erstmal! HW scheidet aus da auf der parallel installierten OS 11.4 alles passt. Gerade nochmal getestet. konstante CPU hab ich auch ggf nicht ganz klar heraus gekommen - wie hoch ist den deine "konstante CPU" - eher 80 -95% (mein Wert 13.1 / 13.2) oder 40-50% (OS 11.4)? -- 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