Re: reiser oder ext3 f
Eduard Bloch schrieb:
> > 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
> 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.
Beweise? Ich habe es so gemacht - mir reicht das als Beweis. Es war die
von Reiser bekannte "kann Datei nicht zugreifen" Situation. Und dann
bin ich in die gleiche Falle getappt, wie viele andere, und dachte "ein
fsck kann nicht schaden". Das war zu dieser Zeit die typische ext2
Angewohnheit, die bei Reiser allerdings öfters fatal verlief.
Das reiserfsck von Anfang 2001 war grottenschlecht und schrieb ja schon
bei reinen read-only Checks Daten auf's Device. Nach einem Check mit
dem Hinweis auf "nur durch --rebuild-tree fixbar", hatte ich diesen
auch gemacht und mit einem Segfault mittendrin war dann der Tree
komplett weg. Weitere reiserfsck Durchläufe ergaben ebenfalls Segfaults
und verschlimmerten die Sache nur.
Ich habe aber 95% der Daten wiederbekommen. Zuerst dachte ich, ich
müsste mir das Rettungstools komplett selber schreiben und hatte mich
entsprechend mit den Reiser-Internas beschäftigt. Zum Glück wurde das
reiserfsck bis Anfang 2002 deutlich besser und lief nach ein paar
vorherigen manuellen Eingriffen dann sauber durch.
Mit der Option -S benötigt es beim --rebuild-tree keinerlei interne
Vorinformationen. Die Tree-Elemente werden an Ihrer Struktur erkannt.
Wenn Du Dir die "Tree Definitions" direkt auf der Homepage von
namesys.com anschaust, findest Du dort sehr oft das magische Wort "Key"
oder "Previous Key". Im Grunde sind diese Keys schon so eine Art "md5
Fingerabdruck". Gibt es an der "Previous" Position ebenfalls eine
Struktur, die nach einem Tree-Node aussieht, bestätigt das die
Zuordnung des aktuellen Sektors zum Tree. Der Baum lässt sich so sehr
gut wieder zusammenfinden. Alle anderen Elemente (root-Block, Bitmaps,
etc.) werden aus den Baum-Informationen abgeleitet, bzw. benötigen
keine Vorinformationen.
Ich denke, die Situation ist die, dass das reiserfsck mittlerweile ganz
brauchbar ist und die Reiser-Struktur eine Art automatisierte Rettung
erlaubt, die es bei ext2 nicht gibt, bzw. dort gar nicht möglich ist.
Nur interessiert es mittlerweile keinen mehr. Viele hatten Ihr
Aha-Erlebnis mit Reiser und haben es schon längst in der Tonne versenkt.
> 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
Bei Reiser befürchte ich, dass es das "Geschmäckle" nicht mehr los
wird. Wenn schon Reiser selbst vor der Verwendung von Versionen vor
2.4.16 warnt, muss man, das Polemisieren mal bei Seite gelassen, ganz
klar sagen, dass die Zeitspanne des "No Bad News" dann einfach geradezu
mickrig ist im Vergleich zu ext2.
Man kann Linus sehr dankbar sein, dass er sich immer vehement geweigert
hat, diesen oder jenen schicken Mode-Hack zu ext2 aufzunehmen. Bei ext3
stelle ich mir die ketzerische Frage "was soll es bringen?". Mir wäre
neu, dass es im laufenden Betrieb etwas bringt.
Für die nach überlicherweise 6 Monaten oder alle 20-30 Systemboots
zwangsweisen fscks braucht man kein neues Filesystem. Es gibt keine
technische Begründung für diese Intervalle und sie sind eine reine
Geschmackssache. Es spricht nichts dagegen tune2fs -c 0 -i 0 zu
benutzen und regelmässige Filesystemchecks zu selbstdefinierten
Wartungszeiten durchzuführen.
Somit bringt ext3 nur im Fehlerfall etwas, wenn das Filesystem unsauber
heruntergefahren wurde. Im professionellen Systembetrieb benötige ich
für diesen "Fehlerfall" aber ebenfalls kein spezielles Filesystem,
sondern eine genaue Analyse der Ursache. Ein volles fsck ist dann
sowieso Bestandteil der Serviceprozedur.
> real 3m54.676s
> Wir stellen fest:
> - Reiserfs ist ungefähr doppelt so schnell beim Durchsuchen, bzw.
Ich weiss nicht, ob man "time" und diese Vorgehensweise als legitimen
Benchmark sehen kann. Eher nicht. Aber es steckt meines Erachtens ein
Stück wichtiger Wahrheit darin. Man sollte die Benchmarks ignorieren
und den Vergleich in der eigenen Umgebung mit dem eigenen Szenario
machen. Ich vermute, dass in den meisten Fällen keine signifikanten
Unterschiede zwischen ext2, ReiserFS und XFS zu finden sind. Nicht nur
bei Messwerten, sondern bei vor allem bei den "gefühlten" Unterschieden.
> 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).
Ich sehe JFS als reine Kompatibilitätsfunktion, wie UDF oder andere und
nicht in der Rolle eines nativen Linux-Filesystems. Die Bug-Darstellung
in der c't ist meines Erachtens unqualifiziert und überzogen. Zumal es
mittlerweile schon wieder mehrere Relases gab.
XFS ist ein hoffnungsvoller Kandidat. Insbesondere in Hinblick auf die
rasant wachsenden Festplatten-Kapazitäten. Die Fähigkeit mit
Filesystemen > 1TiB effizient umgehen zu können, ist schon heute
wichtig und in spätestens 2-3 Jahren auf vielen Workstations
unverzichtbar. Schön wäre, wenn es *jetzt* im Mainline-Kernel verfügbar
wäre. Aber schon die Intergration in den Entwickler-Kernel ist noch
nicht in trockenen Tüchern und erfordert noch eine erhebliche Zahl an
Anpassungen und Veränderungen.
Insofern kann man XFS nur für den dedizierten und nicht den generellen
Einsatz empfehlen. Auch sollte man über die Unterschiede eines Releases
(zur Zeit 1.1) und des kernel-spezifischen Patch (der ein CVS-Snapshot
ist) im Bilde sein. Sozusagen ein "experts only" Produkt.
> Ja. Und die Gefahrenminierung mache ich bald durch mounten aller
> Dateisysteme read-only, ausser /var.
Halte ich gar nichts von. /usr (ro) zu exportieren und zu mounten hat
eine bekannte Tradition, deren Ursprung eigentlich weniger darin liegt,
dass /usr vor überschreiben geschützt ist, sondern vielmehr darin, dass
ein ro mounten auch mehrfach möglich bzw. für einen generellen Export
die bessere Variante ist. Um es nochmal anderes zu formulieren, eher
der Wunsch durch gemeinsames Nutzen von /usr, als der Wunsch des
Schutzes von /usr war für mich der Vater des Gedanken für ro /usr.
Mittlerweile sind die Plattenkapazitäten deutlich gewachsen, der
ursprüngliche Sinn schwindet und die Dinge mutieren, bis hin zu so
abartigen Ideen, selbst /etc ro mounten zu wollen. Jeder ro Mount einer
Standard-Hierarchie entspricht nicht den Vorgaben der Distribution und
führt zu Unbequemlichkeiten oder gar Schwierigkeiten in den vorgesehnen
Abläufen. In der Folge führt die ro Partition genau zu den Problemen,
die sie als vorrangigen wesentlichen Sinn verhindern könnte: Fehler
durch Fehlbedienung. Ein Sicherheitsfeature ist ro sowieso nicht.
> > Du bist Dir sicher zu wissen, wie sich ext3/2 intern unterscheiden?
> Ich denke schon...
> Package: kernel-patch-ext3-2.4
Muss man dazu wirklich ext3 Internas verstehen ;-)
> > 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?
Reset-Taste statt CD-Auswurf unter Volllast... ;-]
> 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.
Was soll es bringen? Ein Fehler, der im Kernel als Fehlerstatus
gehandhabt wird, ist ein "korrekter" Fehler und beantwortet im
Experiment höchstens die Frage, ob das Fehlerhandling funktioniert.
Ich vermute Du möchtest eher Fehler, die der Kernel gar nicht erkennt
oder wahrnimmt. Dazu reicht vielleicht schon zufallsgesteuert das eine
oder andere Bit auf der Platte zu ändern. Aber natürlich nicht das
"magische zentrale" Bit. Schliesslich genügt es noch heute, nur ein
einziges simples Bit zu ändern und schon ist beim nächsten Neustart für
das System die Platte komplett leer.
--
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: