ReiserFS skalierte ab einer gewissen Anzahl von CPUs nicht mehr vernünftig. Außerdem hat die Nutzung des Big Kernel Locks (BKL)teilweise recht hohe Latenzen zur Folge. Das wird ab 2.6.33 behoben sein. ReiserFS skaliert dann ganz ordentlich mit mehreren CPUs. Auf Systemen mit nur einer CPU wird das dafür minimal langsamer sein (der BKL ist ein Spinlock, das neue Locking wird durch einen Mutex realisiert). Spinlocks werden wegoptimiert (sie verschwinden), wenn der Kernel mit CONFIG_SMP=N gebaut wird, bei einem Mutex geht dies nicht, weshalb man immer etwas Overhead hat.
Ich schon. Habs damals (2003-2004) installiert und dann regelmäßig apt-get update; apt-get dist-upgrade aufgerufen.
Merke aber seit 1-2 Jahren, dass, wenn ich zu intensives I/O habe, die Fensterzeichnung nicht mehr richtig funktioniert und der Rechner kaum benutbar wird.
Dachte es würde am reiserfs eventuell liegen, aber da ich ein CPU habe, wird das wohl nicht der Grund sein.
Ja. Wenn viele kleine Dateien anfallen dann ist Reiserfs effizienter als ext3. Da können schon mal 20-30% mehr Festplattenplatz übrig bleiben. Den Unterschied merkt man schon bei einer Systeminstallation ganz ordentlich.
...es Dateisysteme nicht nur vergrößern, sondern auch verkleinern kann, was mit LVM2 die flexible Anpassung der Größen im laufenden Betrieb ermöglicht, ...ich damit noch nie Daten verloren habe, mit XFS und JFS hingegen schon, ...es sparsamer mit dem Plattenplatz umgeht (solange die notail Option nicht verwendet wird), ...ich auch keine weiteren Probleme damit habe.
Solange ich von keinem anderen Dateisystem überzeugt bin dass es diese Kriterien erfüllt, hoffe ich dass Reiser3 genau so weiterentwickelt wird wie es zur Zeit geschieht: In kleinen aber feinen Schritten die die Stabilität und Performance nicht verschlechtern.
Endlich ist der Timm Befehl für SSD Festplaten komplett integriert. Zwar wurde der schon teilweiße mit 2.6.28 eingeführt aber erst mit 2.6.33 vollständig und funktionsfähig.
Von brain fucked am Fr, 18. Dezember 2009 um 15:51 #
Es gab mal wieder einen Benchmark - die Schlussfolgerungen, die manche Leute auf lkml ziehen sind aber arg seltsam - Applikationsabhängige Optimierungen am Scheduler? Das ist doch wirklich nicht das Ziel der Sache. Wenn dann noch Kritik am CFS als Trollerei abgetan wird, dann weiß ich auch nicht mehr.
Sieh dir die Ergebnisse doch mal richtig an. Die Unterschiede sind so gering, daß man das als statistisches Rauschen abschreiben kann. Und später im thread benimmt er sich dann richtig daneben.
oh .- und komisch, daß CFS in Standardeinstellungen bei mir so gut funktioniert, daß ich gar keinen Wunsch verspüre, was anderes auszuprobieren. Woran das nur liegen mag. Man muß bei CFS nichts verstellen. Man KANN. Das ist ein gewaltiger Unterschied.
Von statistik-leser am Sa, 19. Dezember 2009 um 01:40 #
Naja, der CFS ist im Schnitt ~4% langsamer als der BFS (Das Rauschen ist bereits durch die Standardabweichung angegeben), das ist nicht viel, trotzdem stellt sich die legitime Frage, warum das so ist und dass das heißt, dass beim CFS noch Optimierungspotential herrscht.
Wann wird die Versionsnummerierung geändert? Wenn es keine Unterscheidung mehr seit 2.6 zwischen Stabel oder not stabel gibt, dann sollten irgendwann mal über neue Versionsangaben nachgedacht werden. Sonst ist 2020 der Kernel 2.6.2325343534534445345345 der Aktuelle
Von Anonymous Coward am Sa, 19. Dezember 2009 um 19:15 #
Kompletter Unsinn. Es gibt stable und unstable-Releases. Die -rcX-Releases sind unstable, die anderen (2.6.x und 2.6.x.y) sind stable. Interfaces zum Userspace werden in der Regel überhaupt nicht geändert. 2020 ist in 10 Jahren und pro Jahr entstehen ca. 4 Releases. Entsprechend wird man 2020 ca. bei 2.6.73 sein (unter der Annahme, dass die Entwicklung etwa gleich schnell bleibt und das Versionierungsschema nicht geändert wird). Außerdem ist Linus mit dem Entwicklungsprozess sehr zufrieden, schon allein deswegen wird es keinen Kernel 2.8 geben.
> Interfaces zum Userspace werden in der Regel überhaupt nicht geändert. Was ist mit udev und Co.? Aber das sind ja wohl nur die berühmten Ausnahmen. Auch die bereits angekündigte Entfernung von sysctl dürfte strenggenommen erst in einem Kernel 2.7 passieren.
Von PK-Experte am So, 20. Dezember 2009 um 18:03 #
Wenn ich diesen Kernel komplimiere bekomme ich ein Kernel Panic im Kernel Panic? Ich komm nicht weiter. Nachm neustart hängt er in Grub fest. Jegliche änderung erzeugt einen Panic.
Weis jemand, wie sich das dem Benutzer hin geäußert hat?
Benutzt denn noch jemand ReiserFS?
Merke aber seit 1-2 Jahren, dass, wenn ich zu intensives I/O habe, die Fensterzeichnung nicht mehr richtig funktioniert und der Rechner kaum benutbar wird.
Dachte es würde am reiserfs eventuell liegen, aber da ich ein CPU habe, wird das wohl nicht der Grund sein.
Auf Arbeit gibt's auch noch die eine oder andere Partition.
Bis jetzt kann ich mich auch nicht beklagen, wobei ich schon ext2/3/4 bevorzuge.
die Erfahrung hat gezeigt, dass das immer noch am fürsorglichsten mit den Daten umgeht - also kein Datenverlust ^^
(ich hab sie alle durchprobiert: jfs, xfs, ext3, btrfs, ...)
...ich damit noch nie Daten verloren habe, mit XFS und JFS hingegen schon,
...es sparsamer mit dem Plattenplatz umgeht (solange die notail Option nicht verwendet wird),
...ich auch keine weiteren Probleme damit habe.
Solange ich von keinem anderen Dateisystem überzeugt bin dass es diese Kriterien erfüllt, hoffe ich dass Reiser3 genau so weiterentwickelt wird wie es zur Zeit geschieht: In kleinen aber feinen Schritten die die Stabilität und Performance nicht verschlechtern.
Wenn dann noch Kritik am CFS als Trollerei abgetan wird, dann weiß ich auch nicht mehr.
Sieh dir die Ergebnisse doch mal richtig an. Die Unterschiede sind so gering, daß man das als statistisches Rauschen abschreiben kann. Und später im thread benimmt er sich dann richtig daneben.
Siehe auch:
http://marc.info/?l=linux-kernel&m=126113438020198&w=2
oh .- und komisch, daß CFS in Standardeinstellungen bei mir so gut funktioniert, daß ich gar keinen Wunsch verspüre, was anderes auszuprobieren. Woran das nur liegen mag.
Man muß bei CFS nichts verstellen. Man KANN. Das ist ein gewaltiger Unterschied.
http://lwn.net/Articles/351058/
Aber bei Phoronix.com gabs auch schon Benchmarks und bei denen war der BFS auch schlechter...
Wenn es keine Unterscheidung mehr seit 2.6 zwischen Stabel oder not stabel gibt, dann sollten irgendwann mal über neue Versionsangaben nachgedacht werden.
Sonst ist 2020 der Kernel 2.6.2325343534534445345345 der Aktuelle
Außerdem ist Linus mit dem Entwicklungsprozess sehr zufrieden, schon allein deswegen wird es keinen Kernel 2.8 geben.
Was ist mit udev und Co.? Aber das sind ja wohl nur die berühmten Ausnahmen.
Auch die bereits angekündigte Entfernung von sysctl dürfte strenggenommen erst in einem Kernel 2.7 passieren.
Ich komm nicht weiter. Nachm neustart hängt er in Grub fest. Jegliche änderung erzeugt einen Panic.