From owner-cvs-src@FreeBSD.ORG  Tue Oct  4 04:52:11 2005
Return-Path: <owner-cvs-src@FreeBSD.ORG>
X-Original-To: cvs-src@FreeBSD.org
Delivered-To: cvs-src@FreeBSD.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8703C16A41F;
	Tue,  4 Oct 2005 04:52:11 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 00E9543D45;
	Tue,  4 Oct 2005 04:52:10 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j944q0rI020011;
	Mon, 3 Oct 2005 21:52:04 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200510040452.j944q0rI020011@gw.catspoiler.org>
Date: Mon, 3 Oct 2005 21:52:00 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: silby@silby.com
In-Reply-To: <20051003231354.F11061@odysseus.silby.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/ufs/ffs ffs_alloc.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2005 04:52:11 -0000

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.