Date: Wed, 25 Apr 2001 16:43:31 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Oliver Cook <ollie@uk.clara.net> Cc: Ian Dowse <iedowse@maths.tcd.ie>, freebsd-hackers@freebsd.org, iedowse@maths.tcd.ie Subject: Re: open (vfs_syscalls.c:994) && NFS Message-ID: <200104251643.aa54332@salmon.maths.tcd.ie> In-Reply-To: Your message of "Wed, 25 Apr 2001 16:06:57 BST." <20010425160657.B38996@mutare.noc.clara.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200104251643.aa54332>