Lange fsck-Zeiten, ext3, reiserfs (was: Zuviele Inodes - beste Lsung?)
Rainer Ellinger ([EMAIL PROTECTED]) 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
Re: Zuviele Inodes - beste Lsung?
Rainer Ellinger ([EMAIL PROTECTED]) wrote 63 lines: Wolfgang Weisselberg schrieb: Von daher *ist* ext3 nicht nur eine, sondern sogar eine gute und auch noch eine gut skalierende Loesung, die der Admin waehlen kann. Falsch. Was hat ext3 und skalieren in diesem Zusammenhang miteinander zu tun? Skalieren ext2, ReiserFS etwa schlechter? Du redest wirres Zeug. 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. Und da skaliert ext2 -- dein Beispiel(!) -- eben schlecht gegen die Plattengroesse, und ext3 gut. Von Reiser hab' ich hier nicht geredet, aber es skaliert ebenfalls gut -- da beide nicht auf ein fsck uebwe xxx GB, sondern auf ein log replay von nahezu konstanter Groesse (im Verhaeltnis zur Plattengroesse) und damit entsprechend begrenzter Laufzeit angewiesen sind. O(n) und O(c) so -- schon mal gehoert? Ansonsten solltest du etwas, was du nicht verstehst, nicht einfach als wirres Zeug abtun, das kommt nach dem Ende des Mittelalters nicht mehr so gut. Eine andere Loesung als ein nicht-fsck-gebundenes Filesystem[1] zu verwenden, gibt es doch gar nicht, oder? [1] journalled, aber auch phase change tree fs aka Tux2 Hä? Welche Drogen sind das? Weisst du, was ein Google ist? Ich habe wegen und durch ReiserFS Daten verloren, und zwar in kuerzester Zeit. Habe ich auch. Das war anno dazumal. Seit Anfang des Jahres gibt es ein brauchbares reiserfsck. Das heisst, ich soll ein fsck nehmen, das gerade mal ein Jahr 'brauchbar' ist, wenn ich ein ueber Jahre gut getestetes fsck nehmen kann? Wieso soll ich ein FS nehmen, dessen 'stable'-releases Datenkorruption produzier(t)en? Da kann ich ja gleich Win95 nehmen. Bis 2.4.18/19 sind sehr viele Bugfixe für 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, dem traue ich nicht. Fertig aus. Mit ext3 habe ich einige Groessenordnungen mehr Daten einige Groessenordnungen laenger in Betrieb, ohne Daten dadurch verloren zu haben. Wer so redet hat eine 40 GB-Platte .mp3 zu administrieren... Wer so beleidigt, hat keine Ahnung. Und ReiserFS journalled nur die Metadaten. Falsch. Da ReiserFS ohne besondere Angabe beim Mounten automatisch Tails verwendet. Und das journalled die Daten in welcher Weise? Ebenso im Umkehrschluss falsch, da ext3 ohne besondere Angaben beim Mounten nur Metadaten ins Journal schreibt. Dafuer verwendet ext3 per default 'ordered', welches den Effekt hat, dass die neuen Daten D zuerst auf die Platte geschrieben werden und dann erst die Metadaten committed werden -- was dazu fuehrt, dass du entweder ganz D hast (die Metadaten sind committed) oder kein D hast. Das ist -- bezueglich Datenkonsistenz -- im Endeffekt aequivalent zum journallen von D. Rechne es dir durch. Du kannst natuerlich mit data=journal mounten, falls du willst. Kann ReiserFS das? Allerdings braucht das reiserfsck sicher 3x so lange wie e2fsck. Insofern hat ext2 absolut seine Berechtigung. Und reiserfsck kann bei weitem nicht all das, was e2fsck kann. Was ist den das für ein Laber? Ein spezifisches fsck und dessen Funktionen gehören zu einem spezifischen Dateisystem. Jaja, und die Faehigkeit eines fscks, Daten zu rekonstruieren, ist deshalb nicht messbar. ReiserFS ist sogar besser wiederherstellbar, als ext2/3. Ext2/3 ist ohne seine Superblocks am Ende. ReiserFS erkennt seine Metadaten am Inhalt und kann den gesamten Tree daraus wieder herstellen. Nett. Dummerweise ist Reiser ohne Metadaten genauso am Ende. Du darfst jetzt nachschlagen, wieviele Superbloecke es bei ext2 gibt. 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)? Und was genau macht reisefsck, wenn statt einem Ast seines Baumes nur kaputte Metadaten sind? Die Blaetter sind ja noch da und unbeschaedigt -- aber kommt man da dran? -Wolfgang -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Zuviele Inodes - beste Lsung?
Rainer Ellinger ([EMAIL PROTECTED]) wrote 28 lines: ext3 macht es nicht anders, verschwendet nur noch zusätzlichen Platz für ein Journal. Wenn du erstmal 100 GB e2fsck'ed hast, nachdem dir dein System (z.B. Stromausfall) runtergegangen ist -- vor allem, falls es ganz schnell da sein soll: s/w// Thema verfehlt: es ging um Inodes und nicht Reboot. Wohl nicht mehr als mein Vorredner, der die -- oben noch sichtbare -- Aeusserung zu dem Thema ext3 Journal tat. Ich habe ext2-Systeme 100GB. Die brauchen ca. 1 Stunde zum fsck. Wenn das ein Problem darstellt, hat der Admin falsch geplant. Das stimmt schon ... ext3 ist dafür überhaupt keine Lösung. Ext3 verringert die Zeit, die man braucht, um eine nicht sauber geschlossene Partition wieder ordentlich mounten zu koennen. Von daher *ist* ext3 nicht nur eine, sondern sogar eine gute und auch noch eine gut skalierende Loesung, die der Admin waehlen kann. Eine andere Loesung als ein nicht-fsck-gebundenes Filesystem[1] zu verwenden, gibt es doch gar nicht, oder? Bevor ich dafür ext3 wähle, würde ich ReiserFS mehr vertrauen, im Ernstfall nicht zu viele wichtige Daten zu zerstören. Ich habe wegen und durch ReiserFS Daten verloren, und zwar in kuerzester Zeit. Mit ext3 habe ich einige Groessenordnungen mehr Daten einige Groessenordnungen laenger in Betrieb, ohne Daten dadurch verloren zu haben. Und ReiserFS journalled nur die Metadaten. Auch wenn du es nicht glaubst, ext3 ist ext2 + journalling, du kannst ext2fs auf ext3 loslassen. (Ja, das Journal sollte abgearbeitet sein. Nicht antiquierte ext2fs koennen das.) Du kannst sogar ext3 als ext2 mounten, wenn du willst. Allerdings braucht das reiserfsck sicher 3x so lange wie e2fsck. Insofern hat ext2 absolut seine Berechtigung. Und reiserfsck kann bei weitem nicht all das, was e2fsck kann. -Wolfgang [1] journalled, aber auch phase change tree fs aka Tux2 -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Zuviele Inodes - beste Lsung?
Rainer Ellinger ([EMAIL PROTECTED]) wrote 33 lines: ext3 macht es nicht anders, verschwendet nur noch zusätzlichen Platz für ein Journal. Wenn du erstmal 100 GB e2fsck'ed hast, nachdem dir dein System (z.B. Stromausfall) runtergegangen ist -- vor allem, falls es ganz schnell da sein soll: s/w// -Wolfgang -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
