[gelöst]Problem beim Kopieren großer Dateien auf USB-Stick

[VoFiWG]

Beim Kopieren großer Dateien (>1GB) auf USB-Stick oder Speicherkarten friert mir regelmäßig meine grafische Oberfläche (KDE) ein. Das System reagiert bis zum endgültigen Stillstand immer träger. Nachdem die Datei komplett kopiert ist, reagiert das System wieder normal.
Ich glaube, dass es am Arbeitsspeicher liegt, wobei ich davon eigentlich genug haben müsste, nämlich 8GB bei 64bit-System.
Gestern erhielt ich dabei in Chromium die lustige Meldung "Er ist tot, Jim...". :-)

Kann ich dieses Verhalten irgendwie vermeiden oder muss ich mich damit abfinden?

[devil]

Abfinden sollte man sich bei Linux mit garnichts. Sonst kann man beim Marktführer bleiben.

Es gibt nen Thread dazu. Die einzig dort gefundene Lösung scheint die Benutzung eines anderen Schedulers zu sein. Ich hab übrigens das Problem, wie einige andere, auch nicht.

greetz
devil

[VoFiWG]

Vielen Dank für die schnelle Reaktion. Diesen Thread habe ich übersehen.

Bin mir nicht bewusst, bisher einen Scheduler benutzt zu haben. ;-)

Musste mir erst mal was dazu anlesen, um es dann morgen auszuprobieren.

Pah, Marktführer... :-P

Mir ist ein Vogel, der nicht fliegen kann, viel sympathischer, als Fenster, bei welchen ich keinen Durchblick habe.  :lol:

[ralul]

Heise Kernel-Log zu Linux-3.3-rc sagt, dass dieses bekannte Problem endlich gelöst sein soll. Also freuen, in zehn Tagen auf Towos neuen Kernel !

[towo]

Den kann man auch schon jetzt testen, 3.3-rc7 liegt ja in unserem experimental Repo.

[VoFiWG]

Den kann man auch schon jetzt testen, 3.3-rc7 liegt ja in unserem experimental Repo.

... was ich jetzt mal erfolgreich gemacht habe.

Vorher:

System friert beim Kopiervorgang nach einiger Zeit ein bis Datei vollständig auf Stick/Karte geschrieben ist. Kopiervorgang dauert fast 30 Minuten.

Nachher:

1,6 GB große Datei in ~ 1min. 20sec. auf eine SD-Karte kopiert. System jederzeit gut bedienbar.

Ich bin begeistert!

Noch ein paar Infos für Interessierte:

Code Select Expand

~$ cat /sys/block/sdd/queue/scheduler
noop deadline [cfq]

Hier stehen nun nur noch 3 Scheduler, anticipatory war vorher noch zusätzlich vorhanden. cfq war vorher auch als Scheduler eingestellt. Was sich hier unter der Motorhaube jetzt tatsächlich geändert hat, ist für mich nicht nachvollziehbar. Hauptsache der Motor dreht wieder richtig hoch.

Code Select Expand


~$ uname -a
Linux kiste1 3.3-rc7-siduction-amd64 #1 SMP PREEMPT Sun Mar 11 15:42:43 UTC 2012 x86_64 GNU/Linux


Der Beweis, dass ich wirklich den Kernel aus experimental einsetze. ;-)

Nochmal Dank für den Stupps in die richtige Richtung.

[gerd]

Interessant. Ich frage mich nur, woran es lag. Sowohl der Fehler an sich als auch, dass die Behebung mehrere Jahre(wenn mich mein subjektiver Eindruck nicht täuscht) in Anspruch nahm.

[gerd]

http://www.heise.de/open/artikel/Kernel-Log-Was-3-3-bringt-3-Architektur-und-Infrastruktur-1447250.html

[ralul]

@gerd, es ging wohl nur um eine gerechte Verteilung von Dreck. Bei dem, der mehr Dreck macht, soll auch mehr hängen bleiben:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a756cf5908530e8b40bdf569eb48b40139e8d7fd

(Dreckig sind Speicherbereiche, die noch nicht gespeichert oder sonstwie noch nicht fertig bearbeitet worden sind)