> > while the problem will be fixed with following patch,
> > i don't think it's so optimal.
> 
> I agree. KASSERT() is used to test assertions that _should_ be true, so
> much so that we can/should panic if they are false.  In this case it is
> common for the assertion to be false. That seems like a bad candidate for
> a KASSERT().

it must be always true because newly getnewbuf()'ed buffers are
never B_LOCKED.
(and the size of a block for given offset should be invariant normally.)

> > i think that B_LOCKED buffer count/bytes tracking and buffer pinning codes
> > should be moved to some filesystem-independent place from the inside of LFS.
> >
> > any comments/ideas?
> 
> Unfortuantely I don't know LFS well enough to say. But what is wanting to
> grow the block, and why can't the byte counting be updated to cope? I
> think that's the best idea.

in the case that LFS calls allocbuf() directly, the caller can
update byte count as you say.  (see lfs_truncate())

if there's no empty buffers on the free queue, allocbuf()
(called by getblk()) leaves buffers that are larger than desired size.
then, next time getblk() is called for the block, allocbuf() will try to
shrink the buffer to optimal size.  unfortunately LFS can't notice this case.

YAMAMOTO Takashi