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