On Fri, 12 Feb 2016 03:08:04 +0000 (UTC), chris...@astron.com (Christos Zoulas) wrote:
> Ok, do a cvs update (which is what triggers it), wait a bit and then > do the unmount. I'm not quite sure about to what you refer. On a non-stuck client, during 'cvs update' on the NFS server or even arbitrarily long afterward, one can umount/mount an NFS filesystem at will. If the mount point is the PWD or otherwise in use, the umount attempt returns "Device busy". Even on a quiescent 'amd'-managed NFS mount, access to files on that mount during or slightly after a 'cvs update' on the file server will succeed, albeit with some disconcerting delay--as long as 'firefox' isn't running. Pondering other scenarios that could trigger the behavior. Something with a file open on the 'amd'-managed mount during 'cvs update' on the server? The directory is already open as PWD in the shell. Something that writes to a file? I have another client on which I was editing an email during 'cvs update' and it survived (albeit with the aforementioned delay). One thing I think I should check is to get the client stuck and try to umount an NFS file system without deliberately sabotaging the attempt (i.e., don't make it PWD before umount). I expect it will get stuck as well. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645