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

[julien.bellang at free.fr]

Selon Don Lewis <truckman at FreeBSD.org>:

> 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?


My application is on an embedded Hardware in a Train... Its main functionality
is to synchronize files between other embedded systems.


>
> > 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.

Indeed, I've already try in sync mode and write caching off.
In this case the problem desapear (size and blockcount are consistent), but
performance are really too bad and are'nt acceptable.


> 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.

I also tried in sync mode and write caching activated, it was'nt working fine
but I have lost resulting files and I'm not able to tell if the problem with
these files was exactly the same (holey files, or just inconsistent size and
Blockcount).


>
> 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.
>
Unfortunately at that time, I'm not able to Upgrade my system toward FreeBSD
7.0...


More information :

I easely reproducts the problem on a Virtualize machine :
- Install a Minimal FreeBSD 6.2 distro on a Vmware server
- configure a virtualize ATA disk with effective write on an associated local
disk file.
- configure stop server engine action as power off
- copy several big files from on directory to an other and stop the server
engine..



At that time, I'm testing the system with a modified FSCK that truncates regular
file as soon as a hole is detected. It seems work fine, but I have not modified
the source in a generic way at that time : New behaviour is forced (no added
option) and I'm testing FSCK only in forground mode.


Julien Bellanger