will ein Tester mit Kernel 2.6.31 eine geringe Verbesserung bemerkt haben: "There is an improvement in desktop responsiveness with kernel 2.6.31 and the as scheduler compared to the cfq scheduler. It does not solve the problem, but it makes it more sufferable."
Das Hauptproblem ist, dass es keine stabile Kernel-2.6-Reihe von kernel.org gibt (die also jetzt noch supportet wird), die diesen Bug nicht hat. Ich persönlich setze - falls die Hardware es erlaubt - Kernel 2.4 ein, wo es nur möglich ist.
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.
Falls Deine Hardware geeignet sein sollte, so lasse z.B. Slackware 11.0 mit Kernel 2.4 gegen ein neuestes Linux mit Kernel 2.6 antreten und lass deinen Rechner einmal so richtig arbeiten (mitunter reichen schon große Kopieraktionen im Rahmen des Versuchs von "Multitasking"; oder kompilier einen Kernel und arbeite gleichzeitig mit einem anderen Programmen weiter; usw.). Du wirst schnell feststellen, welches System "responsiver" ist.
Kernel 2.6-Systeme verhalten sich unter annähernder Vollast, wenn denn der I/O-Bug zuschlägt, wie damals Win95 beim Formatieren einer Diskette. Siehe hierzu Kommentar 323 unter obigem Link: "The irony is that it feels like Windows 95 while a floppy was formated. You know, the whole pseudo multi tasking on top of Dos - everything was really choppy. (...) If I encode a DVD with ogmrip/mencoder h264 and 16 threads (16 threads get the highest cpu usage from my quad core which is still under 80% per core) Gnome feels like a formatting Win 95."
Von betroffener am Mi, 23. September 2009 um 08:26 #
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link. Doch er ist GERADE auf Desktopsystemen nervig. Kopiere einfach mal ein paar Videos, ISOs, Backup,... von/zu USB-Platten und mach nebenbei was anderes, schon bist du betroffen. Mich nervt der Bug jeden Tag und kotzt mich immer mehr an. Normalerweise sind Bugs unter Linux schnell erkannt und gefixt aber hier wissen die Entwickler nicht mal wo das Problem ist.
Von Michael Lehmeier am Mi, 23. September 2009 um 09:21 #
Wenn das dieser Bug ist, in den ich häufig reinlaufe, dann kann ich bestätigen, dass er nervig ist ohne Ende.
Wenn ich versuche, ein 16 GB Backup auf eine verschlüsselte SATA-Compact-Flash Karte oder USB-Stick zu machen ist die Wahrscheinlichkeit groß, dass der Computer sich so aufhängt, dass nur noch ein Reset hilft. Nur in kleinen Häppchen mit sync dazwischen geht das gut. Das sehe ich nicht als "nicht so wichtig" an.
Dieser I/O-Bug ist tatsächlich nervig. Es aber gut zu wissen, was es eigentlich mit diesem "der Linux-Kernel ist fett und aufgebläht" auf sich hat. Immerhin weißt Du definitiv, dass Du nicht "träumst".
Laut dem letzten Posting in
http://bugzilla.kernel.org/show_bug.cgi?id=12309
will ein Tester mit Kernel 2.6.31 eine geringe Verbesserung bemerkt haben:
"There is an improvement in desktop responsiveness with kernel 2.6.31 and the as scheduler compared to the cfq scheduler. It does not solve the problem, but it makes it more sufferable."
Das Hauptproblem ist, dass es keine stabile Kernel-2.6-Reihe von kernel.org gibt (die also jetzt noch supportet wird), die diesen Bug nicht hat.
Ich persönlich setze - falls die Hardware es erlaubt - Kernel 2.4 ein, wo es nur möglich ist.
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.
Falls Deine Hardware geeignet sein sollte, so lasse z.B. Slackware 11.0 mit Kernel 2.4 gegen ein neuestes Linux mit Kernel 2.6 antreten und lass deinen Rechner einmal so richtig arbeiten (mitunter reichen schon große Kopieraktionen im Rahmen des Versuchs von "Multitasking"; oder kompilier einen Kernel und arbeite gleichzeitig mit einem anderen Programmen weiter; usw.). Du wirst schnell feststellen, welches System "responsiver" ist.
Kernel 2.6-Systeme verhalten sich unter annähernder Vollast, wenn denn der I/O-Bug zuschlägt, wie damals Win95 beim Formatieren einer Diskette.
Siehe hierzu Kommentar 323 unter obigem Link:
"The irony is that it feels like Windows 95 while a floppy was formated. You know, the whole pseudo multi tasking on top of Dos - everything was really choppy. (...) If I encode a DVD with ogmrip/mencoder h264 and 16 threads (16 threads get the highest cpu usage from my quad core which is still under 80% per core) Gnome feels like a formatting Win 95."
Doch er ist GERADE auf Desktopsystemen nervig. Kopiere einfach mal ein paar Videos, ISOs, Backup,... von/zu USB-Platten und mach nebenbei was anderes, schon bist du betroffen. Mich nervt der Bug jeden Tag und kotzt mich immer mehr an. Normalerweise sind Bugs unter Linux schnell erkannt und gefixt aber hier wissen die Entwickler nicht mal wo das Problem ist.
Wenn ich versuche, ein 16 GB Backup auf eine verschlüsselte SATA-Compact-Flash Karte oder USB-Stick zu machen ist die Wahrscheinlichkeit groß, dass der Computer sich so aufhängt, dass nur noch ein Reset hilft.
Nur in kleinen Häppchen mit sync dazwischen geht das gut. Das sehe ich nicht als "nicht so wichtig" an.
Es aber gut zu wissen, was es eigentlich mit diesem "der Linux-Kernel ist fett und aufgebläht" auf sich hat.
Immerhin weißt Du definitiv, dass Du nicht "träumst".