Date: Mon, 3 Oct 2005 21:52:00 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: silby@silby.com Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs ffs_alloc.c Message-ID: <200510040452.j944q0rI020011@gw.catspoiler.org> In-Reply-To: <20051003231354.F11061@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> Log: >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510040452.j944q0rI020011>