Problem concerning the UFS consistency with embedded FreeBSD system

[Bellanger, Julien]

Hi,
 
Summary :
After I shut down the power and ran fsck on FS, the Size field of a file
that was written during the power cut off is corresponding to the final
size of the file to write and not the actual length of the block really
written. FSCK only corrects he FS block metadata information, not the
real file size written.
 
 
I have installed i386 FreeBSD 6.2 system on an embedded card (Kontron
card). This system is installed in an environment where power is cut off
many time a day. 
 
In that condition, I try to maintain and detect as much as possible the
consistency of the FS data flushed on the disk and I discovered a
problem concerning the consistency of the SIZE wrote in I-node
descriptor with the real BLOCKCOUNT associate to this I-node.
 
More precisely if I'm coping 50 files of 10Mb from a directory to
another (via the cp command) and cut the power off in the middle of this
operation :
 
- on reboot the FSCK program detects the incoherence and prints :
    /dev/ad2s1f: INCORRECT BLOCK COUNT I=5205090 (20160 should be 19360)
(CORRECTED)
  so it corrects the BLOCKCOUNT in the associated I-node 5205090
 
- The problem is that the fsck doesn't correct the SIZE in this I-node,
and the announced size is set to the final waiting size even if fsck has
detect the loss of data block... (I can saw that with the fsdb command)
 
- Thus when I remount this File System, the file seems OK with the good
size, but If I read it with VI, I actually only read correct data at the
start of the file (corresponding to the data block that could be read)
and the end of file is filled with bad character (uninitialized data  in
the extended memory alloc due to the incorrect SIZE file information, I
supposed).
 
Is some one able to explain me : 
- why the SIZE memorized in I-node seems always reflect the final size
of the file and not the actual size wrote on disk ?
- why FSCK doesn't correct the SIZE metadata in the I-node block ?
- how I can detect such inconsistency (FSCK doesn't return an error code
in this case)
 
(For your information I have the same problem with a FS where the
SoftUpdate option is disabled)
 
In your advice can we consider that as a bug ? In my mind FSCK should be
able to set at minima the SIZE equal to BLOCKCOUNT data really wrote.
 
 
Thanks in advances for your answers.
 
 
Julien BELLANGER
Capgemini Telecom Media
 


This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.