Ganzes System hakt bei hoher Last (mit UDMA!)
Hallo, 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?!? Mein System: Duron 950 mit 768 MB RAM auf EPOX 8TKA3 (VIA 686B) Betroffene Platte Maxtor 80 GB 7200 UPM an PM-Onboard UDMA5 Partitionen mit Filmen ext3 bzw. vfat (Plextor 241040TA UDMA2 an SM-Onboard - nicht gemountet) (Promise Utra 100 TX2 mit 2. Platte) (IBM 40 GB 7200 UPM an PM-Promise UDMA5 - System liegt auf RAID-0) (Pioneer DVD an SM-Promise UDMA4 - nicht gemountet) SuSE-Linux 8.1 mit 2.4.20-vanilla (ich glaub', mit nicht funktionierendem TIOCGDEV-Patch sowie lm_sensors und i2c-Modulen (geht auch nicht, aber ohne Fehler, findet nichts) und nvidia-Modul (<- läuft _prima_)) (Ich werde wohl noch mal eine andere Mail darüber schreiben, dass beim Kopieren eines Films von vfat nach vfat auf eine andere Partition der gleichen Platte, vielleicht relativ stark fragmentiert, bei mir Transferraten von 0,8 MB/s durchschnittlich vorkommen. Das _ist_ zu wenig, oder?!? Vielleicht hat alles irgendwie miteinander zu tun.) Im Anhang die Ausgaben von hdparm -iv /dev/hd* Grüße, Ré /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 10011/255/63, sectors = 160836480, start = 0 Model=IC35L080AVVA07-0, FwRev=VA4OA50K, SerialNo=VNC400A4L0DU8A Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52 BuffType=DualPortCache, BuffSize=1863kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160836480 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 2 3 4 5 /dev/hdc: HDIO_GET_MULTCOUNT failed: Input/output error IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) BLKRAGET failed: Input/output error HDIO_GETGEO failed: Invalid argument Model=PLEXTOR CD-R PX-W2410A, FwRev=1.04, SerialNo=461029 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic } RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=0kB, MaxMultSect=0 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0 IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 AdvancedPM=no /dev/hde: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 79408/16/63, sectors = 80043264, start = 0 Model=Maxtor 5T040H4, FwRev=TAH71DP0, SerialNo=T4HBQ4HC Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80043264 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-6 T13 1410D revision 0: 1 2 3 4 5 6 /dev/hdg: HDIO_GET_MULTCOUNT failed: Invalid argument IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 1 (on) readahead = 8 (on) HDIO_GETGEO failed: Invalid argument Model=Pioneer DVD-ROM ATAPIModel DVD-116 0122, FwRev=E1.22, SerialNo= Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic } RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=13395, BuffSize=64kB, MaxMultSect=0 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 *udma4 AdvancedPM=no Drive conforms to: device does not report version: 1 2 3 4 5
On Donnerstag, 16. Januar 2003 16:25, René Matthäi wrote:
Hallo,
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) 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 ;-) Steuern kann man das Verhalten etwas in /proc/sys/vm/bdflush, Dokumentation ist in file:/usr/src/linux/Documentation/filesystems/proc.txt und/oder file:/usr/src/linux/Documentation/sysctl/vm.txt aktuell sind aber nur die Sources :-) Mit 'vmstat' kann man nachsehen, was passiert (z.B. vmstat 5) Viel Spass <Earny> PS: vfat <---> vfat 0.8 MB/sec? Viele Dateien pro Verzeichis oder sehr grosse? Dann ist das normal ;-)
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é
participants (2)
-
Ernst Herzberg
-
René Matthäi