Moin Rainer! Rainer Ellinger schrieb am Thursday, den 20. June 2002: > > 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.
Beweise, Watson, Beweise... Um eine solche vollst�ndige Wiederherstellung zu erm�glichen, m�sstest du noch mehr Metadaten mitschleppen, d.h. zumindest eine eindeutige ID in jedem Dateiknoten und jedem Extent. > wichtige Funktionen nur im Source dokumentiert sind (oder waren?). Nach > einigen Odyseen mit ReiserFS habe ich es schon vor 1,5 Jahren endg�ltig Okay, was hast du denn nicht beerdigt? Ich schwanke im Moment zwischen Ext3 und ReiserFS f�r den demn�chst kommenden Server. Ext3 hat im Bekanntenkreis ein Paar Probleme, wenn das Dateisystem vollst�ndig voll�uft (gelegentlich zerschossene Verzeichniss-Bl�cke, wenn zu diesem Zeitpunkt auf die Datei darin geschrieben wurde). Aber f�r Read-Only-Partitionen wohl am besten geeignet (/, /usr). Tempor�re Daten kommen aufs Reiserfs, bei /var bin ich mir noch nicht sicher. Hat jemand bessere Empfehlung? > beerdigt. Die damals entscheidenden Vorteile (tails und journaling) > haben sich durch rasant wachsende Hardware-Kapazit�ten sowieso erledigt > bzw. komplett verlagert. Allerdings. Ich war von den bekannten Benchmarks immer noch nicht �berzeugt, und habe etwas praxisnahes simuliert, Schreiben, Lesen, Durchsuchen des /usr-Inhalts. Test mit Reiserfs: Schreiben: real 3m54.676s user 0m0.520s sys 0m16.630s Lesen: real 1m41.925s user 0m0.670s sys 0m5.110s Durchsuchen: real 0m2.715s user 0m0.040s sys 0m0.140s L�schen: real 0m7.535s user 0m0.070s sys 0m2.560s Reiserfs, notail: Schreiben: real 2m58.039s user 0m0.440s sys 0m14.890s Lesen: real 1m41.882s user 0m0.570s sys 0m4.640s Durchsuchen: real 0m1.086s user 0m0.030s sys 0m0.100s Ditto mit ext2: Schreiben: real 3m20.776s user 0m0.450s sys 0m9.550s Lesen: real 0m29.052s user 0m0.520s sys 0m3.880s Durchsuchen: real 0m6.703s user 0m0.040s sys 0m0.040s Ditto Ext3, defaults: Schreiben: real 3m34.107s user 0m0.440s sys 0m13.430s Lesen: real 0m42.697s user 0m0.610s sys 0m3.730s Durchsuchen: real 0m6.064s user 0m0.050s sys 0m0.100s L�schen: real 0m19.503s user 0m0.060s sys 0m0.770s Ditto Ext3, data=journal: Schreiben: real 3m39.071s user 0m0.420s sys 0m14.100s Lesen: real 0m43.386s user 0m0.620s sys 0m3.830s Durchsuchen: real 0m5.985s user 0m0.060s sys 0m0.050s Wir stellen fest: - Reiserfs ist ungef�hr doppelt so schnell beim Durchsuchen, bzw. ist fast um Gr�ssenordnung schneller wenn mit "notail" geschrieben wurde - Leseperformance ist dagegen lausig, braucht ungef�hr dreifache Zeit (komplexe Datenstrukturen r�chen sich, unter Last wird es wohl noch langsamer). Keine Verbesserung durch notail - Schreiben ist etwas langsamer als Ext2/3, aber etwas schneller mit notail. - Reiserfs mit notail ist richtig fix beim Durchsuchen. - Ext3 schreibt ca. 10% langsamer als Ext2, und liest ca. 30% langsamer - Daten-Journaling kostet nur ein Paar Prozent der Schreib-Performance > 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. Wie gesagt, was bleibt denn da noch? XFS kann ich grade nicht testen, JFS fasse ich nicht an (ist lahm auf AIX und hat laut C't zahlreiche Bugs). > 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. Ja. Und die Gefahrenminierung mache ich bald durch mounten aller Dateisysteme read-only, ausser /var. > Du bist Dir sicher zu wissen, wie sich ext3/2 intern unterscheiden? Ich denke schon... # grep-available Bloch | grep Packa.*ext3 Package: kernel-patch-ext3-2.2 Package: kernel-patch-ext3-2.4 Package: kernel-headers-2.2.20-udma100-ext3 Package: kernel-image-2.2.20-udma100-ext3 > 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. Soso, was f�r "kapitale Ereignisse" sollen das sein? > > 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. Nein, i.d.R. wird es sp�ter neuversucht, und dann geht es wieder. Ich will die Fehler wirklich nur vort�uschen, Simulation im Kernel. Gruss/Regards, Eduard. -- Air DOS: Die Flugg�ste schieben das Flugzeug an, bis es schnell genug ist und gleitet. Dann springen alle auf und fliegen, bis es wieder landet. Danach schiebt man es wieder an, etc. etc. -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
