cvs commit: src/sys/ufs/ffs ffs_alloc.c
truckman at FreeBSD.org
Mon Oct 3 21:52:11 PDT 2005
On 3 Oct, Mike Silbersack wrote:
> On Mon, 3 Oct 2005, Don Lewis wrote:
>> truckman 2005-10-03 21:57:43 UTC
>> FreeBSD src repository
>> Modified files:
>> sys/ufs/ffs ffs_alloc.c
>> Initialize the inode i_flag field in ffs_valloc() to clean up any
>> stale flag bits left over from before the inode was recycled.
> Since these post-crash softupdates issues are so difficult to track down,
> is there a way you could make some regression tests for them?
Most of these problems are pretty nondeterministic. I'd estimate that
this particular bug was hit about once an hour while running Peter
Holm's kernel stress test. The snaplk deadlock problem happened more
often, but there is no way to diagnose the problem and distinguish it
from some of the other deadlocks other than in the debugger.
The background fsck directory link count fixup botch that I fixed in
ffs_softdep.c 1.185 is very deterministic. It shouldn't be too hard to
write a non-destructive regression test for it.
More information about the cvs-all