Subject: Potential NetBSD 1.6 LFS bug
To: tech-kern@netbsd.org, Konrad Schroder <perseant@hhhh.org>
From: Zhihui Zhang <bf20761@binghamton.edu>
List: tech-kern
Date: 03/04/2003 13:11:17
Hi, Konrad:

Thanks for your help on LFS last year. Now I have found a possible bug of
LFS when it deals with fragments. The scenario is as follows:

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.

So the file is written with inconsistent metadata: i_size (say 8161) and
i_lfs_effnblks says it needs 8 fragments, but i_ffs_blocks says it needs
only 5.

Later, the file is re-read probably by lfs_vget(), which will set
i_lfs_effnblks to 5 according to the value of i_ffs_blocks. If we truncate
the file now, it will panic with "persistent blocks" inside
lfs_truncate(). (the value of i_ffs_blocks will become -3)

It seems to me it is legal to have different i_ffs_blocks and
i_lfs_effnblks when cleaning. I do not see any easy solution to this if
this really is a bug.  Any enlightenment is welcome.

Thanks,

-Zhihui

--