meta-data journaling & crashes - wie korrumpierte Dateien finden?

[r. u. serious]

Mir geht es v.a. um XFS, aber wenn ich das richtig sehe, sind prinzipiell alle FS betroffen die nur meta-data journaling machen.

Da viele journaling filesystems nur meta-daten im journal haben, aber nicht die blöcke selbst und weil Dateisystem-Aktionen in der Regel nicht in der Reihenfolge auf die Platte geschrieben werden, in der sie "in Auftrag gegeben wurden, kann es prinzipiell bei einem Crash zu folgendem Problem kommen: Die Meta-Daten sind schon auf der Platte/im Journal, aber die tatsächlichen Inhalte haben es nicht mehr auf die Platte geschafft. Die betroffene Datei ist also möglicherweise korrupt.

1) Gibt es ein Tool mit dem ich feststellen kann welche Dateien betroffen sind und ggf. von einem Backup wiederhergestellt werden müssen?

2) Wenn nicht, warum nicht? Müßte man nicht anhand des Journals (theoretisch) alle zuletzt zum schreiben geöffneten bzw. veränderten Dateien auflisten können, und diese dann darauf testen ob irgendwelche der Extents nur Nulls enthalten?

http://www.ussg.iu.edu/hypermail/linux/ ... .html#0439 (2004)
http://blog.madduck.net/geek/2006.08.11-xfs-zeroes
http://oss.sgi.com/projects/xfs/faq.html#nulls


Es gibt ja hier einige andere User die XFS oder andere meta-data journaling FS benutzen, wie regelt ihr das in solchen Fällen? Erstmal laufen lassen, und schauen ob sich irgendeine Anwendung über kaputte Dateien beschwert?

Ich bin bisher glücklicherweise trotz zahlreicher Crashes und power failures (Notebook wie auch Server), von irgendwelchen Problem verschont geblieben, aber ein ungutes Gefühl bleibt trotzdem immer...

[sogo]

Mir geht es v.a. um XFS, aber wenn ich das richtig sehe, sind prinzipiell alle FS betroffen die nur meta-data journaling machen.

ich kenne nur ext3 ein wenig...

Da viele journaling filesystems nur meta-daten im journal haben, aber nicht die blöcke selbst und weil

ext3 kann data journaling, es ist natuerlich dadurch extrem langsam (war frueher default, daher kommt die legende, dass ext3 langsamer als xfs & co ist...)

Dateisystem-Aktionen in der Regel nicht in der Reihenfolge auf die Platte geschrieben werden, in der sie "in Auftrag gegeben wurden, kann es prinzipiell bei einem Crash zu folgendem Problem kommen: Die Meta-Daten sind schon auf der Platte/im Journal, aber die tatsächlichen Inhalte haben es nicht mehr auf die Platte geschafft. Die betroffene Datei ist also möglicherweise korrupt.

Quasi - im Journal wird vermerkt, dass eine Operation auf die Datei gestarted wurde, dies aber noch nicht beendet wurde.
Ein Journaling Filesystem stellt nur die Integritaet des Filesystems sicher, nicht aber die der Daten!

1) Gibt es ein Tool mit dem ich feststellen kann welche Dateien betroffen sind und ggf. von einem Backup wiederhergestellt werden müssen?

debugfs kann dies fuer ext3, fuer xfs musst du SGI fragen.

2) Wenn nicht, warum nicht? Müßte man nicht anhand des Journals (theoretisch) alle zuletzt zum schreiben geöffneten bzw. veränderten Dateien auflisten können, und diese dann darauf testen ob irgendwelche der Extents nur Nulls enthalten?

http://www.ussg.iu.edu/hypermail/linux/ ... .html#0439 (2004)
http://blog.madduck.net/geek/2006.08.11-xfs-zeroes
http://oss.sgi.com/projects/xfs/faq.html#nulls

Viele Dateien haben legetim Nullen... ansonsten GB's nach Nullen zu greppen kann Zeit kosten
Ich wuerde mich ehrlich nicht darauf verlassen.

Es gibt ja hier einige andere User die XFS oder andere meta-data journaling FS benutzen, wie regelt ihr das in solchen Fällen? Erstmal laufen lassen, und schauen ob sich irgendeine Anwendung über kaputte Dateien beschwert?

rpm -Va macht dies fuer Binaerdaten, ansonsten ist es Applikationssache dies sicherzustellen (Datenbanken, bei denen es wirklich wichtig ist benutzen deswegen Ihr eigenes Filesystem ueber raw devices/O_DIRECT).
Allerdings ist das Problem mit xfs sehr extrem wegen Designproblemen / PC Hardware und ich wuerde es aus diesem Grund nicht auf einem Produktivsystem einsetzen.

Ich bin bisher glücklicherweise trotz zahlreicher Crashes und power failures (Notebook wie auch Server), von irgendwelchen Problem verschont geblieben, aber ein ungutes Gefühl bleibt trotzdem immer...