From owner-cvs-all Thu Jan 3 18: 8: 6 2002 Delivered-To: cvs-all@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 77C0137B419; Thu, 3 Jan 2002 18:07:58 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 4 Jan 2002 02:07:57 +0000 (GMT) To: Robert Watson Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient nfs.h nfs_socket.c nfs_vfsops.c In-Reply-To: Your message of "Tue, 01 Jan 2002 20:22:54 EST." Date: Fri, 04 Jan 2002 02:07:57 +0000 From: Ian Dowse Message-ID: <200201040207.aa52377@salmon.maths.tcd.ie> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Robe rt Watson writes: > >Great, this is something I've hoped to see for ages. I'll try it in the >office tomorrow :-). Hmm, unfortunately there is still one case where hard NFS mounts remain stuck: if getfsstat() is called, e.g from df(1), while an NFS server is unavailable, it will hang in VFS_STATFS() with a vfs_busy() shared lock on the filesystem. If you then try to unmount the filesystem, umount waits forever at the start of dounmount(). Not all callers of VFS_STATFS() currently hold a vfs_busy() lock, but I think that it is a bug that they don't, so removing the vfs_busy() in getfsstat() isn't an option. I'm not sure if there is an easy way to fix this, except perhaps by having a VFS_PREUNMOUNT or something that dounmount() could call before draining mp->mnt_lock. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message