FSCK failed does'nt correct file size when INCORRECT BLOCK
COUNT is found
truckman at FreeBSD.org
Thu Dec 6 22:43:45 PST 2007
On 4 Dec, julien.bellang at free.fr wrote:
> I'm working on a system installed in an environnement where power is cut off
> many time a week. This system is based on i386 FreeBSD 6.2 OS.
> I'm using FS UFS2 with SoftUpdate Activated.
If your disks have write-cacheing enabled, you are likely to encounter
file system corruption caused by the loss of power that can't be fixed
automatically by fsck, which will require manual intervention. The
reason is that soft updates attempts to write data to the disk in an
order that guarantees that the file system is always in a consistent
state so that it can always be properly cleaned up after a crash. This
strategy is defeated by the write caching by the disk, which causes the
disk to immediately tell soft updates that data has been written, even
if the data is only saved to the disk's write cache. This may allow
soft updates to write another set of data to disk that should not
actually be written before the previous set of data. If the disk then
writes the second set of data to the media before the first set of data,
and a power failure occurs before the disk has written the first set of
data, the file system is then corrupted.
You can turn off write caching by putting the following into
though it will greatly decrease your system's disk write performance.
Powering the system using an UPS that can initiate a clean system
shutdown on power failure may be a better option.
> After such power shutdown, when I restart I've got some corrupted files that
> FSCK_UFS doesn't entirely resolve.
> For these files FSCK resolves the following error :
> /dev/ad0s1f: INCORRECT BLOCK COUNT I=3132417 (512992 should be 459392)
> But actually these file still inconsistency in my point of view as the file size
> field doesn't reflect the number of block reference in its inode.
> Regards to fsck_ffs sources, It seems that FSCK checks the validity of block
> pointer (!= 0) in the inode block list only for directory inode but not for
> regular file.
> In my case, as the number of block adress to check in the inode is deduced from
> the file size, and the file size is greater than the number of really allocated
> blocks I obtain many NULL block pointer.
> Does anyone have an idea why the NULL pointer are accepted by FSCK for regular
> file and it doesn't try to adjust the file size ?
Regular files are allowed to be sparse (have holes where no data is
stored and no blocks are allocated). This is indicated by NULL block
pointers for the file offsets that correspond to the holes.
Sparse files are easy to create:
% dd if=/dev/zero of=/tmp/sparsefile bs=512 oseek=1000000 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000132 secs (3876324 bytes/sec)
% ls -ls /tmp/sparsefile
64 -rw-r--r-- 1 dl wheel 512000512 Dec 6 22:26 /tmp/sparsefile
More information about the freebsd-fs