Moin Jens! Jens Benecke schrieb am Wednesday, den 19. June 2002: > > Das kommt drauf an. Vergiss nicht, das ReiserFS eher zusammengehackt > > wurde, > > Das ist IMHO höchst subjektiv, oder hast du den Code komplett gelesen, > verstanden und kannst diese Aussage daher treffen? Natürlich nicht. Aber wenn ich mir die Entstehungsgeschichte betrachte, hab ich ein lausiges Gefühl. Zugegeben, ich hatte über einen Jahr lang meine $HOMEs auf ReiserFS, ohne nennenswerte Probleme. Ein Versuch der Eerstellung von /var scheiterte aber daran, dass der Kernel (einer der ersten 2.4.er) das neue FS nicht erkennen wollte, obwohl die reiserfsprogs aktuelle waren und sonst keine erkennbaren Probleme existierten. > Der Punkt ist viel mehr (aus meiner Sicht, ich bin relativ früh zum > Basteln bei ReiserFS eingestiegen, auf Produktivsystemen aber erst seit > 2.4.1x), daß ReiserFS halt viele Annahmen, die die Kernelentwickler für > Dateisysteme gemacht haben und viele extN-spezifischen Sachen über den > Haufen geworfen hat, und daher anfangs nicht gut funktionierte. Dem stimme ich zu, ich habe mich schon immer gewundert, wieso sich der Wechsel eines Dateisystems so problematisch auf andere Treiber auswirkt, z.B. Ärger mit Samba, mit Quotas usw. (nun ja, die haben im Zuge der Umstellung eine überholte API bekommen). > DIE GLEICHEN "PROBLEME" hatten aber XFS, IBMs JFS usw. auch! Nur hat IBM > die frühen Versionen überhaupt nicht veröffentlicht, und somit wusste JFS ist immer noch ein Problemkind. XFS erfodert massive Änderungen an anderen Teilen des Kernels. > > Auch die Reparaturwerkzeuge sind nicht wirklich zuverlässig. > > Du möchtest nicht wirklich wissen, was e2fsck in den Anfangsstadien > gemacht hat. Rate mal, woher der "a core dumping fsck tends to make me > nervous" Spruch von Linus kommt. ReiserFS gabs damals noch nicht. Toll, mit dieser Aussage implizierst du, dass reiserfs-tools auf dem Stand der ext2progs von 1995 sind. > Die momentan verfügbaren Reparaturwerkzeuge sind in meiner Erfahrung > (und aus Mitlesen der Mailingliste) genauso gut oder schlecht wie die > von extN. Wie gesagt, das will ich gerade anzweifeln. Wenn bei ExtN ein Block nicht mehr lesbar ist, dann trifft es entweder einen Datenblock oder Inode-Block. Das schlimmste, was mir danach passiert ist, war ein Verlust von Dateinamen oder verfälschung des Dateiinhalts (bei IO-corruption). Und jetzt möchte ich ReiserFS sehen, das vollständig auf tolle Bäume vertraut, wie es sich verhalten wird, wenn da ein Stück aus der Datenstruktur gerissen wird. Ich hatte das bisher nur einmal auf einem olen 486er, ReiserFS konnte _nicht_ repariert werden, die Dateien waren weder lesbar, noch konnte man sie löschen. > > Dir-Index macht etwas anderes. Auf Balancierung wird verzichtet, > > stattdessen werden Mehrweg-Suchbäume mit grossen Knoten genommen, u.. > > ..teien Nachteile: Baumhöhe nicht mehr garantierbar. Eine gute > > Wir werden sehen. :-) Ich sehe das dir-index-ext2 momentan wie Windows > ME: Eine erweiterung einer Erweiterung eines Updates eines Patches eines > sehr alten Systems. Ja, und es hat seine Nachteile, vor allem noch grössere Platzverschwendung. Vorteile sind, wie gesagt, die Kompatibilität und Rückgriff auf vorhandene Tools. > > die anderen sind keine Grössen mehr. > > LycosEurope hat angeblich mehrere -zig TB Daten auf ReiserFS. Mag sein, aber die müssen das Zeug auch sichern. Was macht ein Heimanwender, ohne Backup und so? Wie auch immer, man hört immer wieder über Probleme mit ReiserFS, kaputte Dateien, vermeintliche IO-Errors, Korruption der Baumstruktur. Ich will nicht behaupten, dass die Hardware dabei 100%ig einwandfrei funktioniert hat, trotzdem ist der Schaden von IO-Fehlern bei ExtN erfahrungsgemäss gering. > Ich hatte noch mp3.com und sehr viele "cache appliance" Hersteller > vergessen, die finanzieren ihn auch. SuSE unterhält glaub ich auch einen > oder zwei fulltime ReiserFS Entwickler. Ohja, diese Sponsoren spammen dann bei jedem System-Start... An Xu's stelle würde ich die Werbung aus dem Source herausoperieren. > > "Reiserfs' fast journaling" ist schön, aber was nützt das, wenn die > > Inhalte nicht mehr konsistent sind? > > Nichts. Und? Hatte ich noch nicht. Und ich administriere gelegentlich > LAN-Party-Server, da gibt es anfangs öfter als einmal am Tag > Stromausfälle oder ähnlichen Mist. Ohja, immer wieder lustig... > ext2 hat mir nach solchen fällen mehrfach Dateien in /usr/bin o.ä., die > niemals beschrieben wurden, mit "I/O error" bemängelt, die sich nur > durch mehrfaches fsck und Neueinspielen der Dateien beheben liessen. Das ist kein Vergleich, nimm ext3 als Referenz. > ReiserFS hat (auf der gleichen Hardware) auf dem Event mit 120GB > FTP-Server gespielt, war bei den ersten Stromausfällen mit Abstand als > erstes wieder oben und hat kein einziges Problem gezeigt. Und was garantiert dir, das die Dateien hinterher konsistent waren? Ich meine damit vor allem geschriebene Daten. > Ich bin nach meinen Erfahrungen gegangen, und da hat sich ReiserFS > bisher als die bessere Alternative herausgestellt. Nein, 100% problemlos > war es nicht, aber es waren weniger als ich mit ext2 vorher hatte. Ich bleibe bei der Behauptung, das Ext3 zuverlässiger ist. Ext2 konnte zu Datenverlusten führen, klar, auch zur Beschädigung des Dateibaums. ReiserFS in der Default-Einstellung würde unter gleiche Bedingungen vermuttlich die Dateistruktur wiederherstellen (zumindest mit Glück), aber die Datenkonsistenz ist nicht gewährleistet. Ich suche immer noch nach einer Möglichkeit, im laufenden Betrieb IO-Fehler zu faken, um ein Paar realistische Tests zu machen. Gruss/Regards, Eduard. -- "stupidity should be painful" (Neil C. Obremski)
Attachment:
pgpnnkcnr6Rf1.pgp
Description: PGP signature