Re: Dateisysteme unter Extrembedingungen (was: filesystem für /var/spool/news)
Am Montag 10 Juli 2006 09:33 schrieb Jochen Schulz:
> Frank Dietrich:
> > ich hab hier schon seit ca. 1,5 Jahren leafnode installiert. Wenn
> > texpire läuft, dann hört man das die Platte richtig Stress bekommt.
> > Es läuft auch recht lang, >20min. Kann es am nicht optimalen
> > Filesystem liegen? Ich hatte mich seinerzeit für XFS entschieden weil
> > es in diversen Empfehlungen als das geeignetste FS für den News Spool
> > genannt wurde.
>
> Auch wenn es nicht so recht paßt: ich werde sobald kein XFS mehr
> benutzen. Hintergrund: der IDE-Controller meines Notebooks ist kürzlich
> verstorben. Natürlich nicht ganz, nein, er sorgte nur sporadisch für
> fehlgeschlagenen Schreiboperationen, bis der Kernel die Notbremse zog
> und die entsprechende Partition read-only gemountet hat. Dabei haben
> sich naturgemäß alle beteiligten Dateisysteme mehr oder weniger zerlegt.
>
> (Einschub: ja, ich hatte von den wichtigsten Daten restore-fähige
> Backups. Aber nein, ich hatte nicht mein komplettes /etc und /home
> gesichert und ich wollte schauen, was da noch zu holen ist.)
>
> Ergebnisse nach Dateisystem:
>
> ext3: ein e2fsck konnte das meiste retten. Verluste hielten sich in
> Grenzen und die Reparatur ging relativ flott. Ich war allerdings
> hauptsächlich an /etc interessiert (war meine root-Partition) und
> das ist bekanntlich eher klein.
>
> XFS: zu meiner Schande muß ich gestehen, dass ich erst in dieser
> Situation lernte, dass XFS kein übliches fsck anbietet. Die
> manpage von fsck.xfs:
>
> XFS is a journaling filesystem and performs recovery at mount(8)
> time if necessary, so fsck.xfs simply exits with a zero exit
> status.
>
> Das mounten klappte aber leider nicht. Es war IIRC die
> Fehlerausgabe des fehlgeschlagenen Mountversuchs, die mir riet,
> 'xfs_repair -L' zu probieren. Nach der manpage ist das gefährlich,
> aber ich hatte ja auch keine richtige Wahl. Nachdem das
> durchgelaufen war, war *nicht eine* Datei mehr an ihrem Platz.
> Alles wurde nach /lost+found geschoben. Direkt unterhalb dieses
> Verzeichnisses hatte keine Datei und kein Verzeichnis seinen
> ursprünglichen Namen mehr - alles durchnumeriert. :) Soweit ich
> das überblicken kann, wurden einige Dateien mehrfach restored,
> andere dagegen wohl gar nicht. Fazit: nur wenig wiederherstellbar,
> und auch das nur mit großen manuellen Aufwand, da alle Dateien und
> Verzeichnisse wild durcheinandergewürfelt und teilweise umbenannt
> waren.
>
> FAT: Gab etwas mehr Verluste als ext3 und da das die größte Partition
> war, dauerte der fsck auch ziemlich lange (>1h für ~13GB).
> Witziges Erlebnis zwischendurch: weil mir der fsck zu lange
> dauerte und ich zufällig eine Windowskiste neben mir stehen hatte,
> brach ich ab und versuchte es dort (per USB-IDE-Gehäuse). Scandisk
> (ohne badblocks-Test) brauchte nur wenige Minuten - um mir
> mitzuteilen, dass das Dateisystem gar nicht kaputt sei. :) Der
> Explorer weigerte sich aber Verzeichnisse zu löschen, weil
> irgendwo drunter illegale Dateinamen wären... Mit fsck.vfat aus
> dosfstools ging es schließlich.
>
> Natürlich kann ich nicht sagen, ob das XFS durch den kaputten
> IDE-Controller mehr abbekommen hat, als die anderen Partitionen. Da das
> mein /home war, habe ich wahrscheinlich dort auch am meisten
> grschrieben. Es ist also nicht auszuschließen, dass ein ext3 oder
> sonstwas Anderes nicht genau so die Grätsche gemacht hätte. Der direkte
> Vergleich hat mich jedenfalls dazu gebracht, in Zukunft wieder nur auf
> ext3 zu setzen.
>
> J.
Tja kenn ich, ging mir mit zu langem ide kabel so das auch noch nen Wackler
hatte. :-)
Ende vom Lied, ext2 für boot, jfs für / und trotz allem xfs für meine lvm
partionen. Für die Sicherheit sorgt ein offline backup auf Tape.
Ryven
Reply to: