Re: reiser oder ext3 f
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.
--
rainer@ellinger.de
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-german-request@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listmaster@lists.debian.org (engl)
Reply to: