Thanks. I have looked at the solution in current and it is a good one.
Now I have a question about the discrepancy of i_ffs_blocks and
i_lfs_effnblks.

(1) For normal files, these two values should be the same when
lfs_writeinode() is called. This is resolved in an earlier call to
lfs_writefile(). However, the flag B_GATHERED is cleared in an interrupt
callback routine. So it is possible when lfs_writefile() is called, some
dirty buffer are skipped before B_GATHERED is already set. As a result,
the two block counters will be different.  I believe this problem can be
solved by clearing the B_GATHERED in segment write time. Because you use
copy/malloc in segment write, this flag can be cleared as soon as its
content is copied to the segment buffer.

(2) The IFILE seems to be allowed to write inode directly without first
writing its dirty buffers. This seems OK because the inode of IFILE is
always updated into the same place (sp->idp).

(3) If (1) and (2) can be resolved, then the only case when the two
counters (i_ffs_blocks and i_lfs_effnblks) are different happens during
the cleaning. I do not understand why. Could you please help me on this
one?   Thanks.

-Zhihui

On Wed, 5 Mar 2003, Konrad Schroder wrote:

> On Tue, 4 Mar 2003, Zhihui Zhang wrote:
>
> > A small file is initially allocated 5 fragments (one fragment is 1024
> > bytes, one block is 8192 bytes). Then it extends to 8 fragments. The
> > i_size and i_lfs_effnblks are set correctly.  But the value of
> > i_ffs_blocks is still 5. When this file is written, lfs_updatemeta() can
> > not increase i_ffs_blocks properly because (1) the address is not
> > UNWRITTEN (2) it has no way of knowing that it should increase
> > i_ffs_blocks by exactly 3.
>
> Your analysis is right on.  The problem is fixed in -current, though;
> there is an inode extension that records the lengths of the on-disk
> fragments, and lfs_updatemeta updates i_ffs_blocks when it sees the sizes
> change.
> 						Konrad Schroder
> 						perseant@hhhh.org
>
>

--