[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: