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)