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)
msg10840/pgp00000.pgp
Description: PGP signature
