Re: Zuviele Inodes - beste Lösung?
Moin Rainer!
Rainer Ellinger schrieb am Tuesday, den 19. November 2002:
> > 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?
Du interpretierst hier schon fleissig Inkompetenz ein, aber lies doch
erstmal, was da steht.
> 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.
Falsch! Aktuelle Ext2 und Ext3 basieren auf dem Ext2-Tree der letzten
2.2.x-Kernel. Datenformate sind in der Praktisch identisch, es handelt
sich schliesslich nur um eine versteckte Datei und ein Paar Flags im
Superblock, die schon vor langer Zeit reserviert wurden.
> > 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. Mit ext3 in der Version von vor einem Jahr konnte ich
IMO Unsinn. Ich kann mich an keine Crash-Me-Tests mit ReiserFS erinnern.
Sehr wohl aber an welche mit Ext3, durchgeführt von IBM-Entwicklern
("note: sehr gut").
> auch Datenkorruption provozieren. Aufgrund der Konzentration der
> Metadaten auf's Journal, knallt's dabei sogar besonders hübsch.
Interessant. Ich durfte es bisher genau einmal erleben.
> > > 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? 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.
Dir ist schon klar, dass der durschnittliche ReiserFS-User ein SuSE-DAU
ist und keine Bugs meldet? (DISCLAIMER: nichtS persönlich gemeint)
> Superblöcke von Reiser und ext lassen sich nicht vergleichen. 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.
>
> Bei ReiserFS hast Du bei Verlusten in den Metadaten hohe Chancen
^^
Das stinkt so nach Stochastik...
Gruss/Regards,
Eduard.
--
Wenn einer träumt, bleibt es ein Traum.
Wenn viele träumen,
beginnt der Traum, Wirklichkeit zu werden.
--
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 Lösung?
Moin Rainer! Rainer Ellinger schrieb am Sunday, den 17. November 2002: > > > Bevor ich dafür ext3 wähle, würde ich ReiserFS mehr vertrauen, > > 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. Bis 2.4.18/19 sind sehr viele Bugfixe für Gross ist der Glaube... > ReiserFS in den Kernel eingeflossen. Also Winterschlaf vom vorletzen > Jahr beenden und Know-how aktualisieren. Was nützt denn das tolle reiserfsck, wenn der Dateiinhalt mit einem anderen Verheiratet wurde, ohne das ReiserFS das mitbekommt? Hab ich beim letzten Test in 3 von 4 Crashes gehabt, danach flog der Mist wieder runter. ReiserFS ist schön für Temp-Verzeichnisse, weil lokaler User das nicht so schnell DOSen kann, für _sichere_ Datenspeicherung taugt es IMO nicht. > > Und ReiserFS journalled nur die Metadaten. > > Falsch. Da ReiserFS ohne besondere Angabe beim Mounten automatisch > Tails verwendet. Ebenso im Umkehrschluss falsch, da ext3 ohne besondere > Angaben beim Mounten nur Metadaten ins Journal schreibt. Und wie kommst du jetzt überhaupt auf den Zusammenhang Daten-Journalling <-> Tail-Packing? > 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. Klar, aber wieviele Backups verteil ExtX im Dateisystem? ;) Gruss/Regards, Eduard. -- > The 3 R's on bei Microsoft systems: > Retry, Reboot, Reinstall . The 3 F's on Debian-Unstable: Find the bug, Fix the bug, F*k the maintainer -- 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)
Lange fsck-Zeiten, ext3, reiserfs (was: Zuviele Inodes - beste Lösung?)
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 (s
Re: Zuviele Inodes - beste Lösung?
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. 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. > 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? 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. > 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. Mit ext3 in der Version von vor einem Jahr konnte ich auch Datenkorruption provozieren. Aufgrund der Konzentration der Metadaten auf's Journal, knallt's dabei sogar besonders hübsch. > > 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? 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. > Du kannst natuerlich mit data=journal mounten, falls du willst. Sprich, Deine ursprüngliche Aussage war, was sonst: falsch! > Kann ReiserFS das? Nicht ablenken! Wenn schon trollen, dann auch bei der Fütterung immer schön konzentriert bleiben. Obwohl, wozu noch füttern... > 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? Superblöcke von Reiser und ext lassen sich nicht vergleichen. 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. Bei ReiserFS hast Du bei Verlusten in den Metadaten hohe Chancen wenigsten die einzelnen Dateien wieder zu bekommen. 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. > 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? > 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? Ja, mit einem "reiserfsck --rebuild-tree -S". -- [EMAIL PROTECTED] -- 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 Lösung?
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 Lösung?
Wolfgang Weisselberg schrieb: > > 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. Wer lesen kann > 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. > 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? > > Bevor ich dafür ext3 wähle, würde ich ReiserFS mehr vertrauen, > 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. 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. > 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... > Und ReiserFS journalled nur die Metadaten. Falsch. Da ReiserFS ohne besondere Angabe beim Mounten automatisch Tails verwendet. Ebenso im Umkehrschluss falsch, da ext3 ohne besondere Angaben beim Mounten nur Metadaten ins Journal schreibt. > > 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. 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. -- [EMAIL PROTECTED] -- 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 Lösung?
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 Lösung?
Wolfgang Weisselberg schrieb: > > 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. Ich habe ext2-Systeme >100GB. Die brauchen ca. 1 Stunde zum fsck. Wenn das ein Problem darstellt, hat der Admin falsch geplant. ext3 ist dafür überhaupt keine Lösung. Bevor ich dafür ext3 wähle, würde ich ReiserFS mehr vertrauen, im Ernstfall nicht zu viele wichtige Daten zu zerstören. Allerdings braucht das reiserfsck sicher 3x so lange wie e2fsck. Insofern hat ext2 absolut seine Berechtigung. -- [EMAIL PROTECTED] -- 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 Lösung?
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)
Re: Zuviele Inodes - beste Lösung?
Hallo Rainer, Am 19:41 2002-11-07 +0100 hat Rainer Ellinger geschrieben: > >Michelle Konzack schrieb: >mke2fs -T largefile oder -T largefile4 reduziert die Zahl der Inodes >radikal, ohne dass Du die Zusammenhänge der einzelnen Block-Parameter >verstehen musst. Dürften in obigem Fall schon zu wenige werden. Hey, das ist ja cool... Sollte meine nfs-Server doch auf WOODY umstellen. -T gibt es unter SLINK nicht Tschuess Michelle -- 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 Lösung?
Michelle Konzack schrieb: > Frage 2:Wie kann ich herausfinden WIE ich mkfs.ext2 verwendet > habe ? (Optionen: -b -i -m) tune2fs -l /dev/hdXX > normalerweise habe ich die meisten Dateien (derzeit rund 10.000) so > um die 100kByte grösse, weshalb eine Blocksize mit 32 KByte oder 64 > kByte sinnvoll währe... mke2fs -T largefile oder -T largefile4 reduziert die Zahl der Inodes radikal, ohne dass Du die Zusammenhänge der einzelnen Block-Parameter verstehen musst. Dürften in obigem Fall schon zu wenige werden. > Irgendwelche empfehlungen ? - ext3 und reiserfs will ich nicht ext3 macht es nicht anders, verschwendet nur noch zusätzlichen Platz für ein Journal. ReiserFS kennt keine Inodes (emuliert diese nur) und hat eine wesentlich kompaktere Struktur. Bringt je nach Zahl und Art der Dateien zwischen 5-15% mehr nutzbaren Platz im Vergleich zu ext2/3. -- [EMAIL PROTECTED] -- 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)
Zuviele Inodes - beste Lösung?
Hallo, habe einen kleinen nfs-server mit einer 6,4 GByte Platte wobei hda7 als /home gemountet ist. Ein 'df -m' ergibt: Nilesystem MB-blocksUsed Available Capacity Mounted on /dev/hda1 45 11 32 26% / /dev/hda3288 0 273 0% /tmp /dev/hda= 45 17 26 40% /var /dev/hda6144 61 75 45% /usr /dev/hda7 55035263 184 97% /home und ein 'df -i' Filesystem Inodes IUsed IFree %IUsed Mounted on /dev/hda1 120482034 1001417% / /dev/hda3 76608 12 76596 0% /tmp /dev/hda5 12048 672 11376 6% /var /dmv/hda6 381529245 2890724% /usr /dev/hda7 718848 57072 661776 8% /home Frage 1:Wieviel speicherplatz frisst so eine unbenuzte inode ??? Frage 2:Wie kann ich herausfinden WIE ich mkfs.ext2 verwendet habe ? (Optionen: -b -i -m) Sieht so aus, als währe die option -m gleich 1% und -i gleich 8192 aber die -b ist glaube ich 4 kByte, aber ich kann nichts grösseres angeben, denn es gibt laufend Fehlermeldungen. Gut, zur Zeit habe ich extrem grosse Dateien drauf, aber normalerweise habe ich die meisten Dateien (derzeit rund 10.000) so um die 100kByte grösse, weshalb eine Blocksize mit 32 KByte oder 64 kByte sinnvoll währe... Irgendwelche empfehlungen ? - ext3 und reiserfs will ich nicht verwenden aus kompatibilitätsgründen, das das System eine Festplatteplatte im Wchselrahmen ist. Danke Michelle -- 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)
