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. -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)