Quoted Blair Sadewitz <blair.sadewitz@gmail.com>:

> I did not write the information down, but I'm fairly certain I
> experienced this multiple times within the last 2-3 days using a large
> LFS root partition.  I have not gotten it using FFSv[12].
>
> I had intended on switching over to an LFS root, but gave up because
> of this plus [what seemed to be] deadlocks.
>
> If it would help I will partition off some space and get a backtrace
> (this is amd64 and I wasn't running a kernel built with
> -fno-omit-frame-pointer) and line information.

I think it's clear that LFS will never be stable with the current =20
people working on it.  LFS needs to be restructured, like many parts =20
of NetBSD.  It contains a lot of unfactored, densely-nested code.

For example, look at lfs_balloc, lfs_truncate, ....  Those are some =20
terribly long functions that should clearly be =20
refactored/restructured/rewritten?.  They also have XXX comments that =20
are worrisome.

With all of the fine-grained locking that is being added, it also =20
seems clear that refactoring of some code would help, because lock =20
patterns become more clear when the functions don't span multiple =20
pages.  Not only that, the code becomes easier to modify.

My 2 cents,

George