[09:19] <Nod0n[m]> Hi, wenn ich viel Daten auf einen USB-Stick kopiere, dann werden viele Programe langsam. Ich habe z. B. gerade in einem Terminal htop gestartet und ich habe mehrere Sekunden gewartet. htop is jetzt nicht gerade ein grosses Program. Ich habe mir die Load angesehen und ich habe extrem viel IO-Wait. htop liegt aber nicht auf dem USB-Stick. htop selbst liegt auf einer eingebauten SSD und ich hätte erwartet, dass es durch das kopieren auf den
[09:19] <Nod0n[m]> USB-Stick nicht beeinträchtigt wird. Es ist mir egal wie lange es dauert bis die Dinge auf dem USB-Stick sind und ich hatte nicht die Absicht, meinen PC langsam zu machen. Ich lade einfach gerade viel Daten auf den USB-Stick. Ist es ein Problem, weil ich mehrere Dinge zur gleichen Zeit auf den USB-Stick kopiere, oder sollte ich sonst etwas anders machen?
[10:39] <xc> Nod0n[m]: unabhängig von der Ursache für dieses Verhalten: Du kannst mit ionice den Kopierprozess depriorisieren.
[11:13] <Nod0n[m]> Das probier ich mal. 🙂 danke.
[18:21] <tomreyn> Nod0n[m]: iowait heißt im prinzip "wartezeit für das rest vom system, die dadurch entsteht, dass (storage-) i/o-(teil)vorgänge abgeschlossen werden müssen". es ist also das gesamte system davon betroffen, wenn die iowait steigt, denn es betrifft auch die cpu, die die storage-i/o-vorgänge steuert und überwacht, und das RAM, in den die zu kopierenden daten gelesen, und aus dem sie wieder geschrieben werden (aber das RAM ist in der 
[18:21] <tomreyn> regel nicht der limitierende faktor bei iowait, sondern die bandbreite des storage-busses und ein volllaufen der storage-caches - bei längeren kopieraktionen). leider scheint sich unter gnome das parallelisieren von kopiervorgängen auch gegenseitig zu behakeln. bei n gleichzeitigen kopiervorgängen wird (gefühlt deutlich) mehr als die n-fache io-last erzeugt. deswegen würde ich davon abraten, kopiervorgänge auf der GUI zu parallelisieren.
[18:21] <tomreyn>  Aber selbst auf dem CLI ist das meist keine gute Idee, denn auch da ergibt sich mehr (wenn auch nicht im gleichen Maß) als die n-fache Last beim parallelisierten Kopieren, weil der IO-Scheduluer immer wieder (CPU-/Interrupt-basiertes) Context switching veranlassen muss, um die Parallelisierung der Datenübertragungen / des Kopierens aufrechtzuerhalten.
[19:25] <itu> htop zeigt aber jetzt kein "iowait" an, oder?
[19:38] <tomreyn> bin mir da nicht sicher, top sollte es anzeigen
[19:38] <tomreyn> "0.0 wa" in der CPU-zeile bei top
[19:39] <tomreyn> htop kann es auch per setup (F2) -> display options -> Detailed CPU time
[19:45] <empwilli> Guten Abend :). Ich hab seit einiger Weile Probleme mit Avahi. Mir geht's nicht um einen konkreten Service aber ich finde keine Dienste (Drucker o.ä.) mehr.
[19:46] <empwilli> Hab leider keinen konkreten Dienst an dem ichs debuggen kann, aber hab schon verschiedene Netze durchprobiert in denen auf _jedenfall_ Drucker o.ä. da sein sollten
[19:47] <empwilli> Leider krieg ich keine Fehlermeldungen produziert, was mich aber misstrauisch stimmt ist das "n/a" in "+  n/a  n/a speedport.ip" das ich als antwort auf "avahi-browse -D" krieg
[19:47] <empwilli> avai-discover meint zu Interface/Protocol sogar direkt ein -1
[19:47] <empwilli> hat jemand eine Idee wie ich das noch angehen kann? Sollte eigentlich keine iptables Regeln drin haben
[22:21] <tomreyn> empwilli: iptables -L   listet alle firewallkonfigurationen auf
[22:22] <tomreyn> beim eigentlichen problem kann ich aber nicht helfen, kenne avahi zu dafür wenig
[22:22] <tomreyn> *dafür zu wenig