From owner-freebsd-fs  Sat Mar  2 14:42: 4 2002
Delivered-To: freebsd-fs@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 1AD8237B400
	for <fs@FreeBSD.ORG>; Sat,  2 Mar 2002 14:42:01 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.11.6/8.9.1) id g22MftL56881;
	Sat, 2 Mar 2002 14:41:55 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 2 Mar 2002 14:41:55 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200203022241.g22MftL56881@apollo.backplane.com>
To: Ian Dowse <iedowse@maths.tcd.ie>
Cc: Kris Kennaway <kris@obsecurity.org>,
	Kirk McKusick <mckusick@mckusick.com>, Finch <dot@dotat.at>,
	fs@FreeBSD.ORG, fanf@chiark.greenend.org.uk
Subject: Re: UFS panic on -stable 
References:  <200203022233.aa08277@salmon.maths.tcd.ie>
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-fs.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-fs>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-fs>
X-Loop: FreeBSD.org


:In message <20020302135914.A33051@xor.obsecurity.org>, Kris Kennaway writes:
:>So much for the MFS theory:
:>
:>/x: bad dir ino 1006899 at offset 0: mangled entry
:>panic: ufs_dirbad: bad dir
:>Debugger("panic")
:>Stopped at      Debugger+0x35:  movb    $0,in_Debugger.426
:>db>
:>
:>/x is a local UFS filesystem.
:
:Hmm. You said originally that the problem first appeared when the
:cluster was upgraded to 4.5. Was that 4.5-RELEASE or -STABLE? If
:it was -STABLE, the approximate date would help as we can ignore
:commits since then.
:
:One change that I am slightly suspicious of is the moving of the
:VOP_INACTIVE call in vput and vrele. That was MFC'd on Feb 2nd
:(vfs_subr.c revision 1.249.2.25), so I'd be interested to know if
:the crashes occurred before this change. The reason I'm concerned
:about this one is that the NFS client does not use vnode locking
:(vn_lock always succeeds), and nfs_inactive can block, so calling
:VOP_INACTIVE while the vnode is not marked VFREE may cause subtle
:changes in behaviour elsewhere.
:
:Ian

     This is definitely worth trying.

     If it comes down to it, the only way to track the problem down
     may be to cvs update -D<date>, build, install, test and close in
     on the date it broke.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message