From owner-freebsd-fs Sun Mar 3 19:21:30 2002 Delivered-To: freebsd-fs@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id E39AB37B404 for ; Sun, 3 Mar 2002 19:21:14 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id g23JH9g02868; Sun, 3 Mar 2002 11:17:10 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200203031917.g23JH9g02868@beastie.mckusick.com> To: Ian Dowse Subject: Re: UFS panic on -stable Cc: Kris Kennaway , Matthew Dillon , Finch , fs@FreeBSD.ORG, fanf@chiark.greenend.org.uk In-Reply-To: Your message of "Sat, 02 Mar 2002 22:33:14 GMT." <200203022233.aa08277@salmon.maths.tcd.ie> Date: Sun, 03 Mar 2002 11:17:04 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org To: Kris Kennaway cc: Matthew Dillon , Kirk McKusick , Finch , fs@FreeBSD.ORG, fanf@chiark.greenend.org.uk Subject: Re: UFS panic on -stable In-Reply-To: Your message of "Sat, 02 Mar 2002 13:59:14 PST." <20020302135914.A33051@xor.obsecurity.org> Date: Sat, 02 Mar 2002 22:33:14 +0000 From: Ian Dowse 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 Of the recent changes that I have been involved with, the one above is the one that I would be most suspicious of. The problems seem to be showing up independent of soft updates, and the VOP_INACTIVE one is the only change of mine that would have that property. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message