Eduard Bloch schrieb: > 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.
Der Baum l�sst sich besser retten. Die Reiser-Nodes ergeben in sich eine logische Struktur. Das reiserfsck kann ohne jede Vorinformation die ganze Platte Sektor f�r Sektor scannen und alle Baumelemente daran, dass Sie in's grosse Puzzle passen, ziemlich zuverl�ssig herausfischen. Und dann w�ren wir auch schon beim Problem, dass diese und �hnlich wichtige Funktionen nur im Source dokumentiert sind (oder waren?). Nach einigen Odyseen mit ReiserFS habe ich es schon vor 1,5 Jahren endg�ltig beerdigt. Die damals entscheidenden Vorteile (tails und journaling) haben sich durch rasant wachsende Hardware-Kapazit�ten sowieso erledigt bzw. komplett verlagert. Den Code von Reiser halte ich nicht per se f�r grauenhaft, aber die Bugfixes die selbst in den letzten 12 Monaten (nach sooo langer Entwicklungszeit) �ber den �ther kommen, da sind echte Br�ller darunter. Insofern denke ich, dass sich sp�testens in zwei Monaten auch f�r eine breitere �ffentlichkeit die Diskrepanz zwischen Wunsch und Wirklichkeit bei Reiser nicht nur von einem Insider-Publikum erschliessen l�sst. > > ext2 hat mir nach solchen f�llen mehrfach Dateien in /usr/bin o.�., > Das ist kein Vergleich, nimm ext3 als Referenz. Was soll bitte an ext3 besser sein? Dass es Dank Journaling langsamer ist, oder die Tatsache, das in dem von den meisten Leuten benutzten Modus nur Meta-Daten �ber's Journal gehen und dann auch schon der geringste Fehler im Vergleich zu ext2 exponentielle Effekte hat? Ich denke nur an das nette ext3 Problem, dass quer �ber das Dateisystem die Directoryeintr�ge hunderter einzelne Dateien mit v�llig zuf�lligen Werten gef�llt wurden. Das war der Moment, wo ich ext3 (eine Revision vor der Integration in den Mainline Kernel) bereits beerdigt hatte. Fasse ich auch nicht mehr. > > 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. Kein Linux-Dateisystem, weil es schon prinzipbedingt, keine Garantie daf�r hat, was die Platte pysikalisch eigentlich macht. Insofern ist die Dateisystem-Diskussion im Zusammenhang mit Verf�gbarkeit oder Datensicherheit eigentlich m�ssig. Verf�gbarkeit l�st man mit Fail-/Takeover Konzepten, oder wie in obigen Fall mit einer USV. Datensicherheit mit Backup. Beides keine Aufgaben eines heutigen Dateisystems. > > 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 Du bist Dir sicher zu wissen, wie sich ext3/2 intern unterscheiden? ext3 ist strukturell identisch zu ext2. ext3 hat nur noch einen organisatorischen Vorschalt-Aufsatz, der das Risiko verlagert. Weniger kleine, belanglose Probleme und diese auch weniger oft, daf�r h�heres Verlustrisiko bei kapitalen Ereignissen. > Ich suche immer noch nach einer M�glichkeit, im laufenden Betrieb > IO-Fehler zu faken, um ein Paar realistische Tests zu machen. Wechselrahmen mit Ein/Ausschalter und ein wenig am Strom knippsen. -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
