From owner-freebsd-fs@FreeBSD.ORG Thu Apr 9 18:58:22 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEF8C106566B for ; Thu, 9 Apr 2009 18:58:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 6FDC68FC18 for ; Thu, 9 Apr 2009 18:58:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n39IwLT3028367 for ; Thu, 9 Apr 2009 14:58:21 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n39J4bj28859 for ; Thu, 9 Apr 2009 15:04:37 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 9 Apr 2009 15:04:37 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-fs@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Subject: integrating nfsv4 locking with nlm and local locking X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:58:23 -0000 My nfsv4 server currently does VOP_ADVLOCK() with the non-blocking F_SETLK type and I had thought that was sufficient, but I now realize (thanks to a recent post by Zachary Loafman) that this breaks when a delegation for the file is issued to a client. (When a delegation for a file is issued to a client, it can do byte range locking locally, and the server doesn't know about these to do VOP_ADVLOCK() on the server machine.) I believe that Zachary would like to discuss a more general solution, including how to handle Open/Share locks, but in the meantime I'd like to solve this specific case in as simple a way as possible. Basically, I need a way to make sure delegations for a file don't exist when local byte range locking or locking via the NLM is being done on the file. The simplest thing I can think of is the following: When VOP_ADVLOCK() is called for a file (outside of the nfsv4 server), do two things: 1 - Make sure any outstanding delegations are recalled. I already have a function that does this, so it is a matter of figuring out where to put the call(s). 2 - Set a flag on the vnode, so that my nfsv4 server knows not to issue another delegation for that file. (I could test for locks via VOP_ADVLOCK() before issuing a delegation, but that has two problems.) 1 - Since the vnode is unlocked for VOP_ADVLOCK(), there could be a race where the nfsv4 server issues a delegation between the time outstanding delegations are recalled at #1 above and the VOP_ADVLOCK() sets the lock that I would see during the test. 2 - It would have to keep checking for a lock and might issue a delegation at a point where no lock is held, but one will be acquired soon, forcing the delegation recall. (It's much easier to not issue a delegation than recall one.) Once this flag is set, I think it would be ok if the flag remains set until the vnode is recycled, since it seems fairly likely that, once byte range locking is done on a file, more will happen. (If people were agreeable to the vnode flag, it looks like a VV_xxx flag would make more sense than a VI_xxx one. I think an atomic_set_int() would be sufficient to set it, even though the vnode lock isn't held?) So, how does this sound? rick