Am 08.02.2012 07:54, schrieb Joerg Thuemmler:
Am 07.02.2012 22:22, schrieb Matthias Keller:
Hallo Liste
Zumindest seit 12.1 (ev auch schon früher) habe ich das Problem, dass wenn ich grosse Datenmengen auf einen USB-Stick kopiere (in Konqueror), so geht der Balken dort extrem schnell rüber und ist nach wenigen Sekunden fertig. Danach blinkt der Stick jedoch noch laaange weiter (was auch so sein muss, denn die Datenmenge lässt sich nicht in den 5 Sekunden übertragen) - das find ich schonmal merkwürdig.. Ist hier irgendein Buffer aktiv und die Datenmenge wird erstmal ins Memory geschrieben, bevor sie dann langsam auf dem Stick ankommt? Finde es zumindest sehr unnatürlich den Kopievorgang im GUI längst erledigt zu sehen obwohl erst ein Bruchteil der Daten auf dem Stick ist...
ich fürchte, das ist normales Verhalten. Je nach RAM kann das Schreiben aus dem Puffer ziemlich viel sein und noch eine Weile dauern. Merkt man spätestens beim umounten, wenn er busy ist...
Ausserdem wenn ich wirklich viele Daten kopiere (mehrere GByte), dann kann es passieren, dass das System immer langsamer wird und schliesslich fast völlig blockiert bis der Kopierprozess abgeschlossen ist. Mein System Load Viewer zeigt dann hauptsächlich IOWait auf beiden Kernen an, KDE lässt sich jedoch kaum mehr bedienen, auch in einer Konsole gehts nur noch extrem schleppend und manchmal gar nicht mehr - ist das normal? Schaue ich dann in die Ausgabe von top ist meist Xorg mit ca 20% da, gefolgt von plasma-desktop mit ca 10% plus ein paar Kleine, dazu ca 60-70% wait, was ja soweit logisch ist, nur das System so in die Knie zwingen darf es einfach nicht...
uname -a Linux muellhalde 3.1.9-1.4-desktop #1 SMP PREEMPT Fri Jan 27 08:55:10 UTC 2012 (efb5ff4) x86_64 x86_64 x86_64 GNU/Linux
Vielen Dank für eure Tipps
Matti
Letzteres könnte am Stick liegen bzw. am USB-Versionsverhältnis Stick/Port. Kann es sein, dass der Stick noch USB1.1 ist? Bei "ein paar GB" kann da was zusammenkommen, kommt ja auch auf das FS auf dem Stick an und auf die Hardwarequalität...
cu jth
Hallo Matthias, Hallo Jörg, dieses Problem kommt mir sehr bekannt vor. Allerdings ist es schon lange her dass es bei mir auftrat. Vielleicht 1 Jahr ???... Jedenfalls habe ich es damals auf dieser Liste mit einigen Leuten diskutiert. Allerdings ohne wesentliches Ergebnis. Irgend jemand, hab vergessen wer, gab mir auch noch Tips gewisse kernel-parameter zu tunen. Hat aber - so aus der Erinnerung - nicht viel gebracht. Kann mich leider nicht an den Betreff erinnern, sonst könnte man im Listen-Archiv suchen.. Mein *Eindruck* war jedenfalls folgender: Der kernel verwendet den gesamten *freien* RAM als I/O-Buffer was ja durchaus wünschenswert ist. Das Problem ist nun die Definition von "frei". Ich habe das Gefühlt, dass wenn man sehr große Datenmengen kopiert, und mit sehr groß meine ich Dateien die größer sind als der verfügbare physische RAM, beginnt der kernel zu swappen. Sprich, er lagert programmcode aus, zu Gunsten von mehr I/O buffers. Will man parallel zum copy nun etwas anderes tun, müssen diese programmcode-Teile wieder eingelagert werden. Sprich, das System geht in I/O hoffnungslos unter. Das Kopierziel muss kein USB Stick sein, geht auch von disk auf disk. Allerdings kann man mit einerm "langsameren" Kopierziel den Effekt länger beobachten. Starte mal "iotop" von einer root-Konsole (ist standardmäßig nicht installiert, muss man irgend ein Paket installieren), dann so einen großen copy, und beobachte dann iotop. Wie gesagt, ist nur mein Eindruck und nicht "technisch bewiesen". Ich habe leider nicht die Zeit solche Phänomene zu "jagen". Die Diskussion hier auf der Liste führte damals jedenfalls zu keinem Ergebnis. lG Norbert -- I know we've come a long way, We're changing day to day, But tell me, where do the children play? Yusuf Islam, Nov. 1970 -- 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