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)
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?
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?
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?
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?
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)
