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)
