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