Lange fsck-Zeiten, ext3, reiserfs (was: Zuviele Inodes - beste Lösung?)
Rainer Ellinger (rainer@ellinger.de) wrote 93 lines:
> Wolfgang Weisselberg schrieb:
> > Um dich zu zitieren: "Wer lesen kann...." In anderen Worten,
> > haettest du den relevanten Teil nicht entfernt, wuesstest du,
> > dass es um 'Platte unsauber runtergefahren, braucht lange zum
> > fsck' von *grossen* Platten geht.
> Falsch! Geht es nicht. Es geht/ging immer um $SUBJECT.
Falsch! Es kann sich in einem Thread auch um Unterpunkte
handeln. Oder was hat deine Aussage "Es geht/ging immer um
$SUBJECT." mit Inodes zu tuen, haeh?
Du kannst mir maximal vorwerfen, ich haette das Subjekt nicht
geaendert.
> Ausserdem lässt
> sich in einem Medium, wo alles komplett und öffentlich archiviert wird,
> schlecht etwas unterschlagen. Insofern reicht es mir das zu quoten, was
> zum Herstellen des Zusammenhangs ausreicht.
Ich werfe dir aber vor, eben *dies* nicht gemacht zu haben, und
dann meine Aussagen eben aus dem Zusammenhang herausgerissen
abgeurteilt zu haben!
> > Das heisst, ich soll ein fsck nehmen, das gerade mal ein Jahr
> > 'brauchbar' ist, wenn ich ein ueber Jahre gut getestetes fsck
> > nehmen kann?
> Falsch! Du solltest für ext3 überhaupt kein reiserfsck nehmen. Das
> wissen nun aber schon Anfänger, oder?
Jung', ich unterstelle bei meinen Lesern ein Mindestmass an
Intelligenz. Aber -- bewusst oder nicht -- zeigst du dieses hier
nicht.
> Falls Du darauf anspielst, dass ext3 auf eine jahrelange Erfahrung
> zurückblicken könnte, dann ist das so nicht ganz richtig. ext3 ist ein
> eigenständiges Dateisystem, mit eigener Codebasis, die auch nicht
> länger "stabil" ist, wie ReiserFS. Nur die On-Disk-Formate von ext3 und
> ext2 sind kompatibel. Wohlgemerkt "kompatibel", nicht identisch.
Ext3 ist mit ext2 sehr eng verwandt. Es ist trivial, eine sauber
abgehaengte ext3 als ext2 zu mounten. Es ist trivial, aus einer
ext2 eine ext3 zu machen. So 'kompatibel' sind die. Und da
die so kompatibel sind, kann ein nur leicht erweitertes e2fsck
eine ext3-Partition mit dem gesamten gesammelten Wissen ueber
ext2-On-Disk-Formaten -- denn nur darauf arbeitet ein fsck! --
bearbeiten.
Ebenso sind zwischen ext2 und ext3 die Alloziierung von
Platz auf der Platte, von Updates in den Bitmaps und Inodes
und Superbloecken, von allocate-ahead etc. bis hin zum
Fragmentierungsverhalten, Platzverbrauch, etc. pp. usw. usf. ...
alles 'kompatibel'. Die Probleme und Staerken sind bekannt.
Das einzig neue an ext3 _ist_ das Journalling, nicht das ganze
Filesystem.
> > Wieso soll ich ein FS nehmen, dessen 'stable'-releases
> > Datenkorruption produzier(t)en?
> Falsch! Ein aktuelles ReiserFS ist nicht weniger stabil, als ein
> aktuelles ext3.
Wuerdest du bitte einen Beleg fuer diese Behauptung darlegen?
> Mit ext3 in der Version von vor einem Jahr konnte ich
> auch Datenkorruption provozieren.
Das war welche Version? War die als stable gekennzeichnet,
oder nicht? Wo hast du es gemeldet?
> > > ReiserFS in den Kernel eingeflossen. Also Winterschlaf vom
> > > vorletzen Jahr beenden und Know-how aktualisieren.
> > Noe. Wer mir ein Stable vorlegt, das 'critical' Bugs hat,
> ... die Du wann erkannt und wo gemeldet hast?
Beim testen. Da waren die Daten dann weg. War anscheinend
bereits bekannt (nein, brauchst nicht im bts nachzuschauen,
war kein Debian).
> Mal abgesehen, von der
> Wahnvorstellung, das Dir irgend einer etwas "vorlegt", stellst Du eine
> Situation dar, die vermutlich nie stattfand und wo ich davon ausgehe,
> dass sie auch nie stattfinden wird.
In anderen Worten, du bezichtigst mich der Luege und behauptest,
ich sei gesitig nicht ganz auf der Hoehe. Vermutlich, weil
es nicht in dein Weltbild passen will, dass Reiserfs nicht so
perfekt ist. Ich moechte dich bitten derartiges zu unterlassen.
Du darfst meine Argumente gerne zerpfluecken, so wie du es
willst, persoenliche Angriffe hingegen sollten unter deinem
Niveau liegen. Ok?
Wenn eine Distribution, mit OK von Hans Reiser, Reiserfs einbaut,
dann kann ich sehr wohl von 'vorlegen' reden.
> > Du kannst natuerlich mit data=journal mounten, falls du willst.
> Sprich, Deine ursprüngliche Aussage war, was sonst: falsch!
Sprich, du hast, natuerlich, wieder kontextfrei gequotet.
Ich wiederhole daher:
1. ReiserFS journalled *ausschliesslich* die Metadaten. Siehe:
http://www.namesys.com/faq.html#poweroff
Deine Gegenrede, "Da ReiserFS ohne besondere Angabe beim
Mounten automatisch Tails verwendet."[sic] ist kein Beleg
fuer das Gegenteil. Und die Antwort auf die Frage, wie das
denn nun die Daten journallen solle, bist du mir wohlwissend
schuldig geblieben -- du haettest moeglicherweise zugeben
muessen, dich geirrt haben.
Du meintest daraufhin, meine Behauptung muesese im
Umkehrschluss bedeuten, dass ext3 immer die Daten journalle.
Dies ist -- offensichtlich -- logisch falsch. Korrekt ist
jedoch:
2. Ext3 *kann* die Daten journallen.
3. Ext3's Default journalled die Daten nicht (schreibt sie
also nicht doppelt), sondern (siehe das was du
weggeschnitten hast) verwendet ein anderes Verfahren, um
die Konsistenz der Daten zu garantieren.
Natuerlich kannst du das abschalten -- dann bist du auf dem
Stand von ReiserFS V3 -- nur Metadaten-journalling und nicht
atomare Datenaenderungen.
Um 3. verstehen zu koennen, sollte man allerdings wissen, dass
Journalling nicht die einzige Methode ist, um die Datenkonsistenz
zu erhalten; Tux2 ist ein Beispiel dafuer. Da du auch diesen
Teil elegant gesnippt hast, gehe ich davon aus, dass du Google
entweder nicht bedient hast oder das neue Wissen deiner
Argumentation nicht dienlich war.
> > Kann ReiserFS das?
> Nicht ablenken! Wenn schon trollen, dann auch bei der Fütterung immer
> schön konzentriert bleiben. Obwohl, wozu noch füttern...
Also, nein. ReiserFS4 wird das koennen, aber das wird erst
die Tage stable. Und ist ein kompletter Rewrite.
> > Dummerweise ist Reiser ohne Metadaten genauso am Ende. Du darfst
> > jetzt nachschlagen, wieviele Superbloecke es bei ext2 gibt.
> ... eigentlich ist er ja noch voll drauf. Wie wird die Argumentation
> weiter geführt werden? Eine leere Platte lässt sich schlecht wieder
> herstellen?
Und ob sie sich das laesst. Kostet nur viel viel Geld.
> Superblöcke von Reiser und ext lassen sich nicht vergleichen.
Aber genau das hast du doch getan!
> Bei
> Reiser ist der Superblock nur eine Hilfe und nicht wirklich essentiell.
> Bei ext ist ohne die Superblöcke und das Wissen um die gewählten
> Blockgrössen maschinell erst einmal Sendeschluss.
Tsk. Der Superblock hat die Magic Number 0xEF53. Die Anzahl
an Blockgroessen ist sehr beschraenkt. Die Position der
Superbloecke ist in Block 0 und 1 sowie Bloecke, die n ** x, n
\in N, x \in 3,5,7 genuegen (sparse).
Wieso soll da maschinell Sendeschluss sein? Eine derartige
Suche ist fuer einen Anfaenger trivial zu implementieren.
Wenn e2fsck das nicht tut, so mehr aus Sorge, es koennte eine
nicht-ext[23]-Partition zu 'reparieren' versuchen.
> Bei ReiserFS hast Du bei Verlusten in den Metadaten hohe Chancen
> wenigsten die einzelnen Dateien wieder zu bekommen.
Das hast du auch, wenn du bei ext[23] alle Superbloecke
verlierst.
> Bei kleinen
> Dateien, die in den Tail passen sogar eine fast 100%-tige, selbst wenn
> Dir alle anderen Metadaten verloren gingen. Bei ext bist Du ohne Inodes
> am Ende und kannst nur noch puzzeln.
Und -- welche Katasthrophe schlaegst du vor, dass die Inodes zum
groessen Teil verloren gehen, aber die Daten der Files erhalten
bleiben?
> > Ist dir auch klar, das ext2 seine Metadaten an der Position
> > findet (viel einfacher als die ganze Platte zu durchsuchen) und
> > natuerlich auch an der magic number erkennt (Ja, wir koennten
> > auhc die ganze Platte durchsuchen)?
> Ach ja? Und mit welchem Schalter kann ich diese "Magic"-Funktion
> nutzen, wenn Sie so toll funktioniert?
Mit deiner Faehigkeit, auf die Platte zuzugreifen oder
jemanden dafuer zu bezahlen.
> Ja, mit einem "reiserfsck --rebuild-tree -S".
You are strongly encouraged to make a backup copy of the
whole partition before attempting the --rebuild-tree option.
Ich fuehl' mich dann doch gleich schon viel wohler, wenn ich auch
ein Backup der Daten habe.
-Wolfgang
Reply to: