FSCK failed does'nt correct file size when INCORRECT BLOCK COUNT is found

[Don Lewis]

On  7 Dec, julien wrote:
> I can't get a UPS in my environment.

Would it be possible to use a laptop for this application?

> I already tested with the write cache desactivated, but the problem 
> still the same, I obtain files with holes and incorrect size and 
> blockcount. The only difference is that there is less holes and 
> performance are falling down.
> 
> The problem is really easy to reproduce, you have just to copy several 
> big files and shutdown the power in the midle of the copy.

The disk writes for sequential blocks of the file that are generated by
the copy command are probably getting re-ordered by the disk driver in
order to optimize the I/O ordering.  Interrupting this out of order
sequence with a power failure will result in the holey files that you
are seeing.

With FreeBSD 6.x and earlier, about the only thing you can do in this
situation is to use the "sync" mount option in addition to disabling
write caching, which will force each of the writes done by the file copy
to actually copy the data to disk in sequential order.  Unfortunately,
this will reduce write performance even more.

If you use the "sync" mount option without write caching, I suspect that
the files won't look holey to fsck, but some of the blocks of the files
being written at the time of power failure will contain parts of
previously deleted files and other random garbage.  This could be a
security issue if userA's new file could contain some of userB's old
data.

If you were running FreeBSD 7.0, then gjournal+ufs or zfs could be
possible solutions to your problem.  I haven't tried either, so I can't
comment on how well they might work.