Hi, vielen Dank für Deine Mail! Ernst Herzberg schrieb:
On Donnerstag, 16. Januar 2003 16:25, René Matthäi wrote:
ich lasse hier donkey_v59-4-gaps über ed2k_gui mit nice (10) laufen. Nach dem Start prüft oder erneuert donkey die Hashs der ganzen freigegebenen Dateien (bei mir viele große Filme). Man hört, wie donkey auf die Festplatte zugreift, dann regelmäßig kurze Pause (ca. 1 s), während vermutlich das ganze System "nichts" macht (Maus bleibt stehen, "merkt" sich aber die Bewegung; z. B. beim Kopieren von Dateien pausiert der Transfer währenddessen). WARUM?!?
Weil..
der WriteCache des Kernels ist 'schuld' (wenn du kein Hardwareproblem hast). Das hat sich ab der neuen VM ab Kernel 2.4.10(?) geändert: Früher hatten Leseoperationen auf der Festplatte immer Priorität über Schreibvorgänge, d.h. wenn man z.B. den Mousezeiger bewegt, und es müssen dazu Daten von der Platte eingelesen werden, wurden die immer an den Anfang der Warteschlange der wartenden IO's eingefügt. Mit dem 2.4.20 gibt es das nicht mehr, alle IO's werden gleich priorisiert. Das hat zur Folge, das bei einer Kopieroperation er brav von der Platte liest, er hat ja nichts im Cache, die Schreiboperationen gehen aber erstmal ins Cache. Irgendwann ist der Cache voll, der Kernel will sich wieder Platz schaffen und stellt eine _große_ Menge Schreiboperationen in die IO-Queue. Während die abgearbeitet werden, sieht es so aus, als ob der Rechner nichts mehr tut. Passiert ist aber eigentlich das: Der Cache war voll, mit hoher Warscheinlichkeit ist z.B. auch der Mousezeiger ausgepaged worden. Bewegt man nun die Mouse, soll der wieder eingepaged werden, das ist eine Leseoperation, die wird aber ans _Ende_ der IO-Queue hinter die ganzen Writes gestellt. Erst wenn die Schreiboperationen fertig sind, kommt der Mousezeiger wieder. (das ist mehr bildlich gesprochen, entspricht nicht genau den Tatsachen)
Ich denke aber, dass beim beim Re-hashen von donkey der großen Dateien fast nur Leseoperationen stattfinden. Insofern kann ich mich bezüglich meinem Fall nur schlecht in Deine Argumentation hineindenken. Und es hängt ja nicht nur die Maus: Zum Beispiel hängt auch kurz der Sound, und eben auch Kopieraktionen via cp werden kurz unterbrochen.
Das ist kein Bug und auch kein schlechtes Design, eher im Gegenteil. Nur lästig:-) Würden Leseoperationen bevorzugt, kann es im schlimmsten Fall zu Deadlocks kommen, wenn z.B. ein Prozess durch dauerndes Lesen Schreiboperationen verhindert. Wird wohl auch einer der Gründe sein, warum Windows ein Cache *niemals* bis zur vollen Kapazität ausgeschöpft, und erfahrende Serveradmins gerne auf eine Maus verzichten ;-)
Ich ahne aber, was Du meinst (sprich: vielleicht kann mich an ähnliche Situationen erinnern), habe aber leider den Verdacht, dass das hier nicht zutrifft. Hm - seit der 8.1 hab ich echt Probleme, die 8.0 war auch kein Zuckerschlecken. Momentan hab ich dieses Problem hier und Problem beim UDMA-Zugriff auf ATAPI-Devices über ide-cd bzw. ide-scsi. Soll sich erst beim 2.6 ändern :-((( Und beides vergällt mir mein Linux-Feeling langsam ziemlich (obwohl ich _diesmal_ bei Linux bleiben werde, ich bin da übers Kuckucksnest geflogen bzw. bin dabei, hoffe ich). Dazu dann noch ein immer langsamer werdender KDE mit immer(!!) noch nicht gescheit funktionierender Zwischenablage... Mannomann :-/
PS: vfat <---> vfat 0.8 MB/sec? Viele Dateien pro Verzeichis oder sehr grosse? Dann ist das normal ;-)
Naja (unterwindowsnicht), ich hatte schon lange die Vermutung, vfat sei nicht so performant umgesetzt. Sollte SuSE etc. aber auch mal deutlicher schreiben! Bei der nächsten Installation oder wenn ich mal Zeit bzw. Platz finde, schmeiß ich die vfats RUNTER von meiner schönen Festplatte. Nur ein bisschen noch, für 98 zum Spielen und werweißwas. Wobei ich jetzt auch langsam versuche, unter Linux zu spielen (erstmal quake3 und ut und heroes of might and magic III - gibts IV?). Aber für Illustrator, Dreamweaver und InDesign gibt's noch keinen echten Ersatz... (Ja, ich teXe und xfige und emacse) Vielen Dank nochmal und tschüs Ré