From owner-freebsd-hackers Wed Apr 25 8:43:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id A0C3837B423 for ; Wed, 25 Apr 2001 08:43:32 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 25 Apr 2001 16:43:31 +0100 (BST) To: Oliver Cook Cc: Ian Dowse , freebsd-hackers@freebsd.org, iedowse@maths.tcd.ie Subject: Re: open (vfs_syscalls.c:994) && NFS In-Reply-To: Your message of "Wed, 25 Apr 2001 16:06:57 BST." <20010425160657.B38996@mutare.noc.clara.net> Date: Wed, 25 Apr 2001 16:43:31 +0100 From: Ian Dowse Message-ID: <200104251643.aa54332@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010425160657.B38996@mutare.noc.clara.net>, Oliver Cook writes: >However, the more noticeable problem was the processes stuck in >nfsvin because of the broken directory entry. Have you any ideas >as to what would be causing that particular problem which is >plaguing our servers more than the vmopar problem? The processes stuck in "nfsvinval" are just a side-effect of the vmopar problem; they should go away too when you upgrade. I forget the details, but I think the vmopar-hung process is holding some lock so any other processes that try to access the same file hang in nfsvinval. You can probably verify that every time there are processes stuck in "nfsvinval" there is at least one process stuck in "vmopar". I haven't seen any evidence of the broken directory entries you mention - maybe you're reading too far into the struct nameidata fields in "nd". It may be normal for some fields to be uninitialised or point at junk data. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message