On Wed, Jun 19, 2002 at 01:56:55AM +0200, Eduard Bloch wrote: > Moin Jens! > Jens Benecke schrieb am Wednesday, den 19. June 2002: Moin! > > Fazit, extN (n=2,3,...) ist für schmale Systeme wohl sinnvoller, > > ReiserFS skaliert besser, wenn die Ressourcen passen. So war es auch > 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? > und üble Portierbarkeit-Probleme hatte. Wobei man sagen muss (wenn ich den ReiserFS Leuten glaube - und das tue ich), daß viele der Portierbarkeit-Probleme daher kamen, daß der anfängliche VFS-Layer von Al Viro(?) an vielen Stellen zu extN-spezifisch war. Genauso wie NFS: Es war zu extN-spezifisch (z.B. fixe Blockgrößen, sowas hat auch XFS und AFS usw. nicht, aber NFS benötigte es bis vor kurzer Zeit) und daher gabs Probleme. 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. DIE GLEICHEN "PROBLEME" hatten aber XFS, IBMs JFS usw. auch! Nur hat IBM die frühen Versionen überhaupt nicht veröffentlicht, und somit wusste das keiner. IBM hat einfach gewartet, bis die VFS-Layer-Entwickler und die NFS-Entwickler wegen Druck von ReiserFS ihre APIs so "extN-unabhängig" gestaltet haben, daß ihre eigenen Systeme da auch vernünftig reinpassten. > 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. Die momentan verfügbaren Reparaturwerkzeuge sind in meiner Erfahrung (und aus Mitlesen der Mailingliste) genauso gut oder schlecht wie die von extN. > Ich für meinen Teil warte gespannt auf die Portierung des > Dir-Index-Patches auf ext3. ReiserFS verwendet meineswissens B-Bäume > mit variablen Knotenaufbau für Verzeichnisse und Hashing für > Dateilisten und Extents. Mittlerweile (iirc) nicht mehr, sie haben was besseres gefunden (B+ oder B* - Bäume) und für die 4.0 im Herbst gibts wieder was komplett anderes. > 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. > > gedacht - Google, Yahoo, LycosEurope, usw. sind alles Großkunden von > > Hans Reiser. > Für Google möchte ich eine Bestätigung sehen, Lies die kernel-mailingliste. > die anderen sind keine Grössen mehr. LycosEurope hat angeblich mehrere -zig TB Daten auf ReiserFS. 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. > Was ist mit Journalling für Daten (was Ext3 u.a. kann)? Geht, ist aber natürlich langsam (genau wie bei extN). ReiserFS machts (angeblich) so, daß das Journal über die Platte verteilt wird - d.h. es werden bei einem Commit nicht die Blocks umgelegt, sondern nur die Indizes des Journals aktualisiert. Das spart fast die Hälfte an Schreibzugriffen (bei vielen Daten und wenig Indizes). (Ich weiss allerdings nicht ob das jetzt schon drin ist, oder noch "beta" für die nächste Version ist). > "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. 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. 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. 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. -- mfg, Jens Benecke /// www.hitchhikers.de, www.linuxfaq.de, www.linux.ms This mail is an attachment? Read http://www.jensbenecke.de/misc/outlook.html V: Epson Stylus Color 600, 1440dpi, inkl. 4F+4SW-Patronen V: 24x Pioneer SCSI-CDROM, ohne Frontklappe V: 8/40x TEAC SCSI CD-Writer, kann Überlänge
Attachment:
pgpsWtWsPLMrh.pgp
Description: PGP signature