Date: Mon, 28 Aug 2006 15:19:17 -0700 From: Can Sar <csar@stanford.edu> To: FreeBSD-questions@FreeBsd.org Subject: UFS2 fsck Question (semantics of -p) Message-ID: <34A15B01-CECC-478F-8EE8-3AEA839803C7@stanford.edu>
next in thread | raw e-mail | index | archive | help
Hi,
I work on a project to automatically (by dynamically running the
system) find crash recovery errors in storage systems and we are
beginning to do some preliminary checking of FreeBSD. We found an
"error" where on power failure the disk can get corrupted even after
an operation has returned successfully on a synchronous mount. Fsck
running with the -p option cannot fix this error, while running it
without, does happen to fix it (in this particular test case).
However, the fsck manfile says the following:
"The kernel takes care that only a restricted class of innocuous file
sys-
tem inconsistencies can happen unless hardware or software
failures
intervene. These are limited to the following:
Unreferenced inodes
Link counts in inodes too large
Missing blocks in the free map
Blocks in the free map also in files
Counts in the super-block wrong
These are the only inconsistencies that fsck_ffs with the -p
option will
correct; if it encounters other inconsistencies, it exits with
an abnor-
mal return status and an automatic reboot will then fail. For
each cor-
rected inconsistency one or more lines will be printed
identifying the
file system on which the correction will take place, and the
nature of
the correction. After successfully correcting a file system,
fsck_ffs
will print the number of files on that file system, the number
of used
and free blocks, and the percentage of fragmentation."
Would you consider it an error if the -p option does not fix
inconsistencies caused by a simple power failure, without any
hardware or software corruption?
I have two example ufs2 images of such errors that you can download.
http://keeda.stanford.edu/ufs-umount-image
http://keeda.stanford.edu/ufs-mount-sync-image
Thank you very much for your help,
Can Sar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34A15B01-CECC-478F-8EE8-3AEA839803C7>