ReiserFS Crash: Lohnt fsck bei 900GB oder gleich Backup einspielen

[pc-nico]

Hallo Leute,

durch einen Systemabstutz wurde ein ReiserFS System mit ca. 900 GB größe beschädigt...

lasse gerade eine reiser fsck laufen... allerdings meint der das es noch über 10000s dauert...
(also ca. 3 Stunden....)

nun meine Frage lohnt dieser Check überhaupt? Werden die Daten danach wieder lessbar sein?

Er spückt massig melduungen aus....

.verify_directory_item: block 8207444, item 2377194 2377205 0x30722500 DIR (3), len 4008, location 88 entry count 97, fsck need 0, format old: All entries were deleted from the directory
block 8555107: The number of items (3) is incorrect, should be (0) - corrected
block 8555107: The free space (4) is incorrect, should be (4072) - correcte

Außerdem immer meldungen das Berechtigungsflags nicht richtig gesetzt sind...

?r--rwxrwx corrected to -r--rwxrwx (so in etwa....)

was meint ihr? Macht der Check und das --rebuild-tree noch einen sinn, oder werde ich danach nur Sinnlose Daten vorfinden? Wäre für eure Meinung dankbar....




PS:
In den Logs habe ich folgendes Gefunden... der Fehler im Dateisystem trat im Laufenden Betreib, wohl durch den Ausfall einer Festplatte des Raid 5 Systems auf....

May  4 04:02:38 SERVER kernel: ReiserFS: warning: is_tree_node: node level 19666 does not match to the expected one 2
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-5150: search_by_key: invalid format found in block 6063142. Fsck?
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [12 2119678 0x0 SD]
May  4 04:02:38 SERVER kernel: ReiserFS: warning: is_tree_node: node level 19666 does not match to the expected one 2
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-5150: search_by_key: invalid format found in block 6063142. Fsck?
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [12 2119697 0x0 SD]
May  4 04:02:38 SERVER kernel: ReiserFS: warning: is_tree_node: node level 19666 does not match to the expected one 2
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-5150: search_by_key: invalid format found in block 6063142. Fsck?
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [12 2119682 0x0 SD]
May  4 04:02:38 SERVER kernel: ReiserFS: warning: is_tree_node: node level 19666 does not match to the expected one 2
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-5150: search_by_key: invalid format found in block 6063142. Fsck?
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [12 2119676 0x0 SD]
May  4 04:02:38 SERVER kernel: ReiserFS: warning: is_tree_node: node level 19666 does not match to the expected one 2
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-5150: search_by_key: invalid format found in block 6063142. Fsck?
May  4 04:02:38 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [12 2119675 0x0 SD]
May  4 04:02:38 SERVER kernel: ReiserFS: warning: is_tree_node: node level 19666 does not match to the expected one 2
May  4 04:02:39 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-5150: search_by_key: invalid format found in block 6063142. Fsck?
May  4 04:02:39 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [12 2119683 0x0 SD]
May  4 04:02:39 SERVER kernel: ReiserFS: warning: is_tree_node: node level 53937 does not match to the expected one 1
May  4 04:02:39 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-5150: search_by_key: invalid format found in block 93116178. Fsck?
May  4 04:02:39 SERVER kernel: ReiserFS: cciss/c0d1p1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [2540018 2540366 0x0 SD]
May  4 04:02:39 SERVER kernel: ReiserFS: warning: is_tree_node: node level 53937 does not match to the expected one 1

 

[Keruskerfürst]

Ich würde die Reparatur des Dateisystems laufen lassen und mir dann das Ergebnis ansehen.

 

[pc-nico]

ok, danke....

hatte nur den gedanken, das wenn jemand so einen fall auch schonmal erlebt hat und dann nur noch Datenmüll vorgefunden hat, es sindvoller wäre die Zeit bereits fürs einspielen
des Backups zu nutzen.... thx

Hier nochmal so eine Meldung wie ich oben schon ansatzweise beschrieben habe:

ass0: block 74171876, item 2: The file [2436606 2436877] has the wrong mode (lrwxr----x), corrected to (-rwxr----x)

 

[Bâshgob]

PS:
In den Logs habe ich folgendes Gefunden... der Fehler im Dateisystem trat im Laufenden Betreib, wohl durch den Ausfall einer Festplatte des Raid 5 Systems auf....

Das sollte allerdings nicht passieren. Definitiv nicht. Da muß noch was anderes Faul sein an der Maschine, wenn ein Plattenausfall in einem RAID 5 derartige Auswirkungen zeigt.

 

[pc-nico]

genau das glaube ich auch..... an dem System ist schön öfter mal eine Platte ausgefallen und das Betriebssystem hat davon sonst auch nie etwas mitbekommen... neue Platte gesteckt, rebuild startetet und keiner hat etwas gemerkt...

allerdings weiß ich auch nicht wo ich nach dem Fehler suchen soll....
ich lasse mir *.* nach /var/log/all loggen und in diesem Log konnte ich nichts auffälliges finden, bis auf die Meldungen die ich oben schon gepostet habe....

 

[Aqualung]

Reiser + RAID1(Hardware) keine "gute" Kombination. Erfahrung: reiserfsck "reparierte" in einem Fall das Dateisystem komplett unlesbar.
Ob RAID5 günstiger ist, weiß ich nicht. Wenn möglich, besser auf ext3 umstellen. Also ich würde auf alle Fälle das Backup einspielen.

Gruß Aqualung

 

[pc-nico]

kann das jemand bestätigen?

Hier wird seit Jahren reiser fs auf Raid 5 (Hardware RAID!) eingesetzt und es gab nie Probleme dieser art.... Wenn ein Platte Defekt war wurde sie ausgetauscht und das BS/Filesystem hat davon nie etwas mitbekommen/abbekommen....

 

[Bâshgob]

Da sind die Meinungen geteilt. Manche schwören darauf, andere raten ab. Persönlich würde ich auch eher ext3 empfehlen, aber das ist nur eine subjektive Meinung.

 

[pc-nico]

dann würde es doch bei einer 900 GB Platte sind machen, die Standardgröße für einen I-Node zu ändern...

den bei 8 KB wären das 11.764.800 I-Nodes....

Zur Zeit liegen ca. 2,5 Mio Dateien auf der Box und belegen etwa 600 GB....
Also wären 16 KB pro I-Node wohl eine vernünfige Größe oder?

(Wie sieht das mit dem Filesystemcheck bei einem Systemabsturz aus,
der Dauert doch dann länger als bei Reiser oder irre ich jetzt?)

 

[hex]

Für große Partitionen haben wir XFS, um noch ein Dateisystem in den Raum zu werfen. Hatte zu meiner Linux-Anfangszeit unter Gentoo ReiserFS und auch einen Datenverlust. Als Laie hab ich zwar keinen Rebuild gemacht, aber seit dem ist es mir schon etwas mulmig unter ReiserFS. Völlig unverständlich ist mir, warum SLES10 das Dateisystem als Standard vorsieht. Aber pauschal kann man glaub nicht sagen, welches Dateisystem das Beste ist. Denke da hat jeder seine eigenen Erfahrungen. Für Daten haben wir in der Firma jetzt ZFS. Das ist halt schon _das_ Killerfilesystem gerade.

OnTopic: Versuch einen Rebuild. Mit Backup im Rücken hast ja nicht viel zu verlieren! Erfahrungen kann ich leider keine bieten!

mfg

 

[sinn3r]

Der gute Herr Reiser sitzt ja nicht umsonst im Gefaengnis... :>

Kann ansonsten hex nur zustimmen...

 

[pc-nico]

danke für die Hinweise...

allerdings möchte ich nicht auf noch ein Dateisystem setzen....

würde also wohl auf ext3 wechseln, wenn der check wirklich nur noch Datenmüll
zurückbringt....

ist meine Denkweise bzg. Inodes je 16KB Dateiblock nachvollziehbar, oder sollte ich die Standard 8 KB verwenden?
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
so phase 4 vom check hat begonnen... aber die ausgebe von phase 3 lässt wohl nichts gutes vermuten:

Flushing..finished
        Objects without names 270758
        Empty lost dirs removed 1212
        Dirs linked to /lost+found: 6120
                Dirs without stat data found 609
        Files linked to /lost+found 264638
        Objects having used objectids: 24645
                files fixed 24258
                dirs fixed 387

 

[saeckereier]

Ich kann nur obige Erfahrungen bestätigen, hab auch so meine Datenausfälle mit ReiserFS hinter mir... Allerdings wird es ja eben weil SLES Standard auch in vielen firmen eingesetzt..

Ich setze mittlerweile auf xfs und ext3 nach Laune..

 

[Bâshgob]

Der gute Herr Reiser sitzt ja nicht umsonst im Gefaengnis... :>

*Das* war jetzt fies. Ein schlechtes Filesystem zu schreiben ist mit Mord nicht ganz vergleichbar