Dateisystem-Fehler im Betrieb beheben

[jay-zi]

Hallo.

Nachdem unser 1&1-Server gestern wegen eines Controller-Fehlers abgestürzt ist, treten nun vereinzelt Probleme mit dem Dateisystem auf. Im rescue-Mode habe ich zwar fsck.ext3 laufen lassen - ohne Befund - nun sind aber doch Fehler vorhanden. Gemeldet wird dies wie folgt:

Code: Select all

/usr/bin/du: cannot access `/home/htdocs/web5/html/img/abc123.jpg': Unknown error 990
/usr/bin/du: cannot access `/home/htdocs/web5/html/img/abc1234.jpg': Unknown error 990
/usr/bin/du: cannot access `/home/htdocs/web5/html/img/abc12345.jpg': Unknown error 990
/usr/bin/du: cannot access `/home/htdocs/web5/html/img/abc12356.jpg': Unknown error 990
/usr/bin/du: cannot access `/home/htdocs/web5/html/ab/abcd/img': Unknown error 990
/usr/bin/du: cannot access `/home/htdocs/web5/html/ab/abcde/img': Unknown error 990

Die korrupten Ordner lassen sich auch nicht löschen und nicht überschreiben. Wie bekomme ich es nun hin, das Dateisystem möglichst im laufenden Betrieb zu reparieren?

Vielen Dank für Eure Bemühungen
Jörg

[thorsten]

Wenn /home eine eigene Partition ist, häng sie aus und teste sie nochmals mit fsck.ext3 -f.
Im laufenden Betrieb würde ich das sonst nicht riskieren, die paar Minuten offline sind besser als im worst-case einige für die Neuinstallation und das Zurücksichern des backups ;)

[jay-zi]

Hi Thorsten.

Danke für den Tipp.

Habe ich eben genauso versucht. Meldung:

Code: Select all

p:/ # fsck.ext3 -f /dev/sda7
e2fsck 1.34 (25-Jul-2003)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext3: Bad magic number in super-block while trying to open /dev/sda7

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Das klingt etwas beängstigend. Wie gesagt, bis auf die zwei Ordner und ein paar Grafiken ist die gesamte Partition okay. Inwieweit ist denn der vorgeschlagene Vorgang (e2fsck -b 8193 <device>) sicher genug, ohne dass die Partition geschädigt wird?

Gruß
Jörg

[oxygen]

Sicher dass es sich überhaupt um ext3 (und nicht um reiserfs, was typisch für /home wäre) handelt?

[thorsten]

sorry, ich bin betriebsblind. Ich bin von einer debian-Installation und somit ext3 ausgegangen.
Wenn du SuSE hast, wird es wohl, so wie oxygen bemerkt hat, wirklich reiserfs sein.
Aber das weißt du sicherlich am besten. Wenn nicht, hilft ein Blick in die fstab oder mtab.
Bei reiserfs magst du also das tool reiserfsck laufen lassen.

[jay-zi]

Ähm... Manchmal ist es aber auch verzwickt. Danke für den Denkanstoß. Tatsächlich handelt es sich um eine XFS-Partition. Die werde ich nacher mal mit xfs_check und gegebenenfalls mit xfs_repair bearbeiten. Oder gibt es für den Zweck 'bessere' Tools?

Gruß
Jörg

[jay-zi]

Mit xfs_repair hat es bestens geklappt. Da es im normalen Modus im ungemounteten Zustand nicht klappen wollte (Fehlermeldung: /dev/sda7 is writeable), habe ich das System wieder in den rescue-Modus gesetzt und die Partition dort in Ruhe reparieren lassen. Vorher erstmal mit xfs_check nach Infos geschaut, dann xfs_repair per Schalter /n befragt, was es denn zu reparieren gedenkt und dann ohne Schalter kurzen Prozess gemacht. Die Code-Kette:

Code: Select all

xfs_check /dev/hda7
xfs_repair -n /dev/hda7
xfs_repair /dev/hda7

Bei mir wollte xfs-repair nicht sofort loslegen, sondern nörgelte erst einmal rum:

Code: Select all

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed.  Mount the filesystem to replay the log, and unmount it before re-running xfs_repair.  If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.

Kurz die Partition gemountet und wieder ungemountet sorgte dann dafür, dass xfs_repair schnell loslegte.

Wenn mal was klappt, macht es auch Spaß. :-D

Gruß
Jörg