Date: Thu, 6 Dec 2007 22:43:35 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: julien.bellang@free.fr Cc: freebsd-fs@FreeBSD.org Subject: Re: FSCK failed does'nt correct file size when INCORRECT BLOCK COUNT is found Message-ID: <200712070643.lB76hZYm063956@gw.catspoiler.org> In-Reply-To: <1196788551.47558b47ee317@imp.free.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Dec, julien.bellang@free.fr wrote: > > Hi, > > 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 /boot/loader.conf: hw.ata.wc=0 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) > (CORRECTED) > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712070643.lB76hZYm063956>