fsck

Der Shell-Befehl fsck prüft ein Dateisystem. Das Dateisystem darf während der Überprüfung durch fsck nicht eingehängt sein. Die automatische Ausführung von fsck kann entweder durch einen Systemabsturz oder durch das Erreichen einer vorbestimmten Anzahl Einhängevorgänge verursacht werden.

Da es unter Unix üblich ist, die veränderten Daten erst einmal in einem "buffer cache" zu halten und nur von Zeit zu Zeit auf die Festplatte zu schreiben, kann es bei einem Absturz zu Inkonsistenzen der Dateisysteme kommen. fsck kann dieses Problem normalerweise beheben. Bei Unix-Systemen mit grossen Festplatten kann das allerdings zu sehr langen Bootvorgängen (bis zu mehreren Stunden) führen.

Eine allfällige Reparatur kann (hoffentlich) mit den fsck-Programmen (e2fsck, ufsck usw.) durchgeführt werden. Wenn fsck einen Fehler nicht beheben kann, so werden entweder sehr gute Kenntnisse von Dateisystemen oder gute Sicherungen benötigt.

Verwendung

Beispiel

Achtung: Nachfolgendes Beispiel ist nicht zur Nachahmung auf produktiven oder sonst wichtigen Systemen empfohlen. Eine falschen Handhabung von dd kann einen irreparablen Schaden auf dem Dateisystem bewirken!

Diskette einlegen und laden.

# volcheck

Anzeige der Partition.

# df -k

Unter anderem sind diese beiden Zeilen zu sehen.

/opt on /dev/dsk/c0t0d0s4 setuid/read/write/largefiles on Mon Dec 18 11:50:34 2000
/floppy/unnamed_floppy on /vol/dev/diskette0/unnamed_floppy setuid/read/write/largefiles on Tue Dec 19 13:01:13 2000

Diskette aushängen.

# umount /floppy/unnamed_floppy

Nun wird der Superblock auf der Diskette zerstört.

# dd if=/dev/rdsk/c0t0d0s4 of=/vol/dev/rdiskette0/unnamed_floppy \
    bs=512 count=1 iseek=16 oseek=16

Anschliessend wird die Schandtat begutachtet.

# fsck /vol/dev/rdiskette0/unnamed_floppy

fsck kann diese Partitionstabelle nicht mehr lesen, da der Superblock zerstört ist. Obwohl alle Daten noch intakt sind ist dieses Dateisystem so nicht mehr brauchbar.

Nun wird nachgesehen, wo Sicherungen des Superblocks angelegt wurden als dieses Dateisystem angelegt wurde. Mit den Optionen "-Nv" wird die Dateisystemerstellung nur simuliert und angezeigt, aber nicht durchgeführt.

# newfs -Nv /vol/dev/rdiskette0/unnamed_floppy

Eine Ausgabe dieses Befehls könnte wie folgt aussehen.

/vol/dev/rdiskette0/unnamed_floppy:     2880 sectors in 80 cylinders of 2 tracks, 18 sectors
        1.4MB in 5 cyl groups (16 c/g, 0.28MB/g, 128 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 640, 1184, 1792, 2336,

Die erste Sicherung ist hier auf Block Nummer 32. Es gibt noch weitere Sicherungen auf 640, 1184, 1792 und 2336. Die erste wird nun verwendet, um mit fsck den Superblock wieder herzustellen.

# fsck -F ufs -o b=32 /vol/dev/rdiskette0/unnamed_floppy

Eine Ausgabe dieses Befehls könnte wie folgt aussehen (das "y" nach "SALVAGE?" muss eingegeben werden!).

Alternate super block location: 32.
** /vol/dev/rdiskette0/unnamed_floppy
** Last Mounted on 
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? y

2 files, 9 used, 1254 free (14 frags, 155 blocks,  1.1% fragmentation)

***** FILE SYSTEM WAS MODIFIED *****

Nun wird nachgesehen, ob alles wieder in Ordnung ist.

# fsck /vol/dev/rdiskette0/unnamed_floppy

Es sollten keine Fehler mehr angezeigt werden und alle Daten sind nach dem Einhängen mit mount wieder verfügbar.

Die Diskette wird nun eingehängt.

# mount /vol/dev/diskette0/unnamed_floppy /floppy/unnamed_floppy

Nun wird der Superblock nochmals zerstört und dies mit fsck geprüft.

# fsck /vol/dev/rdiskette0/unnamed_floppy

Dises Mal wird das Problem nicht wie zuvor behoben sondern es wird folgender Befehl eingegeben.

# sync

Nun wird die Partition wieder mit fsck getestet - was ist passiert?