From owner-freebsd-fs@FreeBSD.ORG Sat Nov 8 13:05:13 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E234D16A4CE for ; Sat, 8 Nov 2003 13:05:13 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 449BB43FDF for ; Sat, 8 Nov 2003 13:05:13 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 33A892ED461; Sat, 8 Nov 2003 13:05:13 -0800 (PST) Date: Sat, 8 Nov 2003 13:05:13 -0800 From: Alfred Perlstein To: fs@freebsd.org Message-ID: <20031108210513.GM34063@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: RFC: removing shared vnode locks in nfs. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2003 21:05:14 -0000 I am requesting a second pair of eyes to make sure I can get rid of shared locks under nfs client. The reason we have shared vnode locks in FreeBSD for NFS is because otherwise if a NFS server goes away we race to the root and halt the whole machine. However, since rev 1.39 of vfs_lookup.c we avoid this by using an interlock with vfs_busy() when crossing into a new mountpoint. Since vfs_busy itself is a shared lock we can have multiple procs stuck on that file system but they will have dropped the parent directory lock, so we may wind up with a bunch of blocked processes, but not a race to root. FYI, Apple has been using exclusive locks on NFS for over two years without problems because they have the equivelant of 1.39 in their vfs_lookup.c. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684