• [gelöscht]

  • Beitrag Nr. 11
Hi SID,

jo das hab ich ja oben schon vermutet. Das es der Scheduler im kernel ist.

Andere Distributionen (Hab F15 komplett installiert gehabt, GRML als LiveCD) haben das Problem nicht.

Gibts Kernelalternativen die sich lohnen? ck-Patches sollen ja gan gut sein.

Probier ich heut abend ma.

Grüße
Für alle Blockdevices kannst du den scheduler per Kernelparameter (an die kernel-Zeile im Botloader anhängen) ändern:
elevator=deadline
(wechselt vom default cfq auf deadline).

Du kannst die IO-Scheduler auch per Blockdevice wechseln. verfügbar sind noop, deadline und cfq(default).
Siehe: 
zgrep -i sched /proc/config.gz
Für jedes Blockdevice (evtl. mal konzentrieren auf das USB-Device und die Zielplatte) kannst du den Scheduler erfahren/wechseln: 
# < /sys/block/sdc/queue/scheduler
noop deadline [cfq]

# echo deadline > /sys/block/sdc/queue/scheduler
# < /sys/block/sdc/queue/scheduler
noop [deadline] cfq
Eine Übersicht über die IO-Scheduler sollte sich in der kernel-Dok finden, einen Artikel auf Deutsch(von 2005!) habe ich für den 2.6er gefunden (Als Einstieg sicher noch ok):
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2005/04/Kern-Technik2
und ggf.
http://forums.gentoo.org/viewtopic-t-619496.html

//Edit: der Anticipatory-Schedulerb ist seit 2.6.33 nicht mehr im Kernel, für langsamere Flah-Medien(evtl. dein Problem mit Sticks) soll der "dumme" noop evtl. der bessere sein...
//Edit2: Selbst mit "langsameren" U/SB-Flashmedien habe ich hier (selbe testumgebung wie oben) keine Probleme - weder lesend noch schreibend. Auch an Intel Atoms nicht, allerdings habe ich dort kein Video+Sound zum testen. kann es gerne heute abend nochmal an einem T60 probieren...
GerBra schriebFür alle Blockdevices kannst du den scheduler per Kernelparameter (an die kernel-Zeile im Botloader anhängen) ändern:
elevator=deadline
(wechselt vom default cfq auf deadline).
habe das mal gemacht, zumindest jetzt grad hängt nix beim kopieren von großen Dateien auf USB Stick.
Sonst wurde zum Beispiel ab und zu mal das Firefox Fenster "gegraut" und hat nicht mehr reagiert.

  • [gelöscht]

  • Beitrag Nr. 14
Cool ..

habs nu auch ma geändert und ich sach ma: läuft gut!

Ich behalte das mal ein paar Tage im Auge 🙂

Grüße
Hmm, wundert mich ein wenig.
Der deadline IO-Scheduler ist laut Dokus eher für Systeme mit "wilden", nicht sequentiellen Diskzugriffen (z.B. datenbankserver) geeignet. Gut, auch für Systeme mit vielen Disks (die aber dann mehr oder weniger gleichzeitig IO haben sollten und/oder kein TCQ beherrschen)...

Aber für eine "einfache" Kopieraktion...?
Der cfq ist eigentlich von seiner Intention her auf Desktop-Systeme ausgelegt...
@SiD: Der Noop, ja (schrieb ich ja auch im ersten Posting). Aber ich denke, ihr nutzt doch jetzt den daedline?? /Me verwirrt....
Den Noop will man aber doch nicht als Default-Scheduler für alles....
Ja stimmt, also ich habe jetzt deadline zur Kernelzeile hinzugefügt und das hier in die rc.local 
echo "cfq" > /sys/block/sda/queue/scheduler
echo "cfq" > /sys/block/sdb/queue/scheduler
Das sind meine internen System-SSD und Datenfestplatte. Hatte mal eine große Datei von sdb nach sda (SSD) kopiert. mit den verscheidenen Schedulern.
cfq -> cfq war am schnellsten.

Angesteckte geräte bekommen ja jetzt den deadline 😉

EDIT://
hmm habs grad nochmal getestet mit den gleichen Dateien und dem gleichen Stick, Problem tritt trozdem auf. Auch mit "deadline only".

EDIT://
Also, nach reboot mit elevator=deadline (einträge aus rc.local wieder entfernt) bleibt jetzt wieder nichts hängen.
Scheinbar hat das Umschalten, des Schedulers was ausgemacht.
Also das kann ihc mir zwar nicht vorstellen, aber könnte es was mit den 8GB RAM zu tun haben. Bin mir jetzt nicht sicher, aber ich meine als ich noch "nur" 4GB verbaut hatte trat das nicht auf.
Also ich habe gleiches Verhalten bei nur 2 GB RAM. Hab jetzt die scheduler noch nicht weiter ausprobiert
@SiD: Ich habe auch 8GB - und (wie immer eigentlich <g>) keine Probleme....
Hier hat ein ThinkPad T60 ebenfalls keine Probleme.
25 Tage später
Mich würde jetzt mal interessieren, ob es möglich ist den scheduler beim anstecken von USB-Sticks für diese automatisch auf noop zu setzen, aber nicht für usb Platten.
Da müsste irgendwie erkannt werden dass es ein Stick / Flash Speicher ist. Geht das?

EDIT://
Das unterscheiden zwischen Flashspeicher (USB-Stick) und Festplatten, muss nicht unbedingt sein, was es denke ich einfacher machen würde.
Also geht es irgendwie dass alle an USB angesteckten Geräte automatisch den noop Scheduler zugewiesen bekommen?
Das Zauberwort heißt wohl udev. Damit kann man beim Hinzufügen von Hardware bestimmte Scripte/befehle ausführen (lassen).