Date: Sat, 2 Mar 2002 14:41:55 -0800 (PST) From: Matthew Dillon <dillon@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 Message-ID: <200203022241.g22MftL56881@apollo.backplane.com> References: <200203022233.aa08277@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203022241.g22MftL56881>