|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Erstaunlich viele Überraschungen in diesem Test...
Im Moment habe ich zwar gerade kein Linux drauf (hab den PC flach gemacht. Für Debian warte ich noch die kurze Zeit, bis ich ADSL habe :-)), aber ich werde wohl ReiserFS oder JFS nehmen...
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. May 2004, 12:04 MEW (#2)
|
|
|
|
|
Die Tests überzeugen mich nicht so recht. Filesysteme wie Ext2 oder Ext3 machen es sich zum Beispiel recht einfach beim Löschen von Dateien. Die ausgeklügelten Datenstrukturen und der damit verbundene Overhead der anderen Dateisysteme machen sich erst dann bezahlt, wenn man (wie in der Realität) viele Male hintereinander Dateien liest und schreibt (Fragmentation auf der HD als auch innerhalb der verwendeten Datenstrukturen), wenn man zufällig auf eine Position innerhalb einer Datei zugreift usw.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich finde die Tests auch ziemlich lau. Anstatt einer wirklichen Harddisk haette er fuer die meisten Tests auch eine Ramdisk benutzen koennen. Find ueber 10000 Verzeichnisse? Das sind ~ 40Mbyte, passt locker in den Cache.
Eine Riesenmenge Grafiken, die meisten davon ohne sinnvolle Aussage. brrr
Interessant waere, wenn er die Tests paralell laufen liesse.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. May 2004, 12:52 MEW (#6)
|
|
|
|
|
Nun ja, Benchmarking ist so 'ne Sache. Der "remove-Files" Test ist z.B. so eine Sache, denn ext2/ext3 benötigen deutlich mehr Zeit, grosse Dateien zu löschen, als kleine, während andere Systeme (bei XFS weiss ich es sicher) dort besser skalieren. Wahrscheinlich finden sich für jedes der getesteten Filesysteme Vorteile, die im Test nicht ersichtlich sind, weil die Benchmarks nicht besonders vielfältige Operationen berücksichtigt haben.
Und trotzdem finde ich die Resultate interessant.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. May 2004, 01:00 MEW (#17)
|
|
|
|
|
5. Bei Programmen und Bibliotheken: dauernd.
usw. Dateien sind nicht nur das, was man im $HOME anlegt, sondern auch Programme und deren Daten, z.b. in /usr/share.
|
|
|
|
|
|
|
|
|
|
|
|
|
Programme: Einmal vollstaendig geladen (vom Filesystem aus, vom Virtual Memory aus, sind es Seiten).
Libraries: einmal vollstaendig geladen und in den Hauptspeicher gemappt (vom Filesystem aus).
|
|
|
|
|
|
|
|
|
|
|
|
|
Wie stabil ist ReiserFS denn mitlerweile?
Ich habe zwar selber noch keine negativen Erfahrungen damit gemacht (aber mit anderen FS auch nicht), aber schon einiges übles gehört.
Die andere Frage, die mich beschäftigt ist, wie verhalten sich diese FS wenn man das FS in seiner größe ändern will?
(Damit meine ich nicht nur vergrößern sondern auch verkleinern)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ReiserFS soll inzwischen sehr stabil sein.
Ich bleibe vorläufig trotzdem bei ext3. Dies vor allem, weil die Umstellung einfach ist,und die sehr ausgereiften und gut getestetn ext2-tools weiterhin verwendet werden können.
|
|
|
|
|
|
|
|
|
|
|
|
|
Reiserfs ist anfaellig auf Bad-Blocks auf der Platte.
Hier gilt doppelt: Backup bereithalten.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. May 2004, 01:09 MEW (#18)
|
|
|
|
|
Es kann Zufall sein, aber bei meinem letzten Platten-Crash (16000 kaputte Sektoren auf die ersten 80GB der Platte verteilt, d.h. 0.01% aller Daten futsch) liessen sich nach dem dd_rescue auf die Garantieplatte alle reiserfs halbwegs wiederherstellen, nur das ext3 nicht.
reiserfsck --rebuild-tree leistete im gegebenen Rahmen ganze Arbeit, e2fsck hat gar keine entsprechende Option "alles futsch, rette was noch geht", sondern versuchte, lauter "normale" Fehler zu reparieren und verfing sich offenbar in einer Endlosschleife wegen Ueberforderung.
Egal, wie man das deutet, aber zumindest sind reiserfse bei Bad-Blocks durchaus reparabel.
|
|
|
|
|
|
|
|
|
|
|
|
|
Was mir da fehlt ist der load des Systems. Reiserfs produziert nämlich viel mehr load als ext3; soviel dass es auf einem 486er fast unmöglich zu benutzen ist.
--
"The more prohibitions there are, The poorer the people will be"
-- Lao Tse
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. May 2004, 00:06 MEW (#16)
|
|
|
|
|
Kommt drauf an, was man will. Selbst moderne HDs können mit modernen Prozessoren nicht mithalten, da kann es durchaus Sinn machen, den Prozessor ein bisschen mehr und dafür die HD ein bisschen weniger arbeiten zu lassen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. May 2004, 14:49 MEW (#11)
|
|
|
|
|
ReiserFS ist schon seit 2.2.16/2.2.17
stabil, die Instabilitäten mit dem 2.4.1/2.4.3/2.4.4/2.4.5
konnte man umgehen, wenn man die original Patches
für 2.4.0 benutzt hat, 2.4.2 war problemlos,
wobei ich selber auch seit 2.4.2 den jfs-support
selber in die 2.4.xxer serie bis 2.4.17
reingepatched habe, und jfs für meine
Belange besser skaliert als ein reiserfs
mit dem std.hashing, da ich eine Mischung aus
grossen und kleinen Dateien auf meiner Platte habe, über die Unzulänglichkeiten von ext2/ext3
habe ich nicht lange lamentiert,
ext3 ist beim fsck, nach einem crash arg langsam
und kommt nicht unbedingt zu einem befriedigenden
ergebnis, wer auf Datensicherheit bedacht ist,
für den sind jfs und reiserfs die geeignetsten
Kandidaten, reiserfs wenn man mehr kleinere Dateien hat, jfs wenn man grosse Dateien über
einen smb/nfs/ftp server Bereitstellt, also
z.B. für einen movie/mp3 server ist jfs geeignetter, für einen Webserver mit vielen kleinen png´s/jpgs/skripten und Seiten hingegen
reiserfs, und die FS mischen ist unter GNU/Linux
auch kein Thema für die Root partition würde
ich aber generell jfs empfehlen,
wenn es mal nicht gemountet werden kann,
Knoppix rein, booten
fsck.jfs /dev/blub6
dann ist sie wieder mountbar
|
|
|
|
|
|
|
|
|
|
|
|
|
Der Crash & Reboot-Test. Wie lange braucht das FS nach einem richtigen Crash mit Schreib-Ops zu dem Zeitpunkt, wieder da zu sein - sprich Dauer des fscks. Ext2 kann da bei einigen zig GBs schonmal einigen Stunden nachdenken. Das ist bei produktiven Systemen nicht so toll. Zumal ext2 so einen fsck auch schonmal ohne Crash auf Zeit oder Boot-Count macht.
Dann die Frage, wie gut das Ergebis ist: sind alle Dateien wieder da und welche fehlen bzw. welche Daten fehlen. Darin liegt doch des Sinn des Jounals, solche Fälle anzudecken.
Bei einem Airbag frage ich auch nicht, ist er weicher oder das Gas darin duftet besser. Ich will wissen, wie schnell er im Einsatzfall reagiert. Daß das Lenkrad deswegen schwerer zu drehen ist, ist mir da zwar der erste Test (ok, merkt man wohl kaum) und einfach, aber reicht nicht.
So kann man aber der FS-Vergleich sehen, ich untersusche das Lenkrad, ob es noch genauso reagiert, wie ohne Airbag (ext2). Einige der Filesysteme sind eben irgendwo sogar schneller (haben also eine Servo), andere Langsamer.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jein... sicher sit das Journal fü den Crash-Fall gedacht, aber es darf die Kiste nicht zu sehr ausbremsen. Wenn der Aurbag so gross und schwer wäre, dass dein Auto nur noch halb so schnell fahren kann (oder doppelt soviel Sprit säuft), würdest du wohl auch verzichten.
Ausserdem ist ja das genau der Witz von ext3 gegenüber ext2, dass dann der fsck nach einem crash nimmer so lange dauert. Aber es hat mir auch schon etwas downtime beschert, weil der fsck fand, dass er das fs schon mehr als 180d nimmer geprüft habe (ja, könnte ich ausschalten, wird aber ned empfohlen). Wird das bei anderen Filesystemen nicht gemacht?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wir hatten in der Firma vor 3 Jahren mal ein Raid aus 12x20 GB, da dauerte der Check ne gute halbe Stunde.
--
ok> boot net - install
|
|
|
|
|
|
