VOP_LEASE

[Jeff Roberson]

On Sat, 12 Apr 2008, Alfred Perlstein wrote:

> * Jeff Roberson <jroberson at jroberson.net> [080412 16:51] wrote:
>>
>> On Sat, 12 Apr 2008, Alfred Perlstein wrote:
>>
>>> * Jeff Roberson <jroberson at jroberson.net> [080412 16:13] wrote:
>>>> On Sat, 12 Apr 2008, Doug Rabson wrote:
>>>>
>>>>>
>>>>> On 12 Apr 2008, at 18:03, Kirk McKusick wrote:
>>>>>
>>>>>>> Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST)
>>>>>>> From: Jeff Roberson <jroberson at jroberson.net>
>>>>>>> To: arch at freebsd.org
>>>>>>> Subject: VOP_LEASE
>>>>>>>
>>>>>>> As far as I can tell this has never been used.  Unless someone can show
>>>>>>> me
>>>>>>> otherwise I'm going to go ahead and remove it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jeff
>>>>>>
>>>>>> VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file
>>>>>> is modified locally so that they know to update any outstanding
>>>>>> leases (e.g., evict any write lease for the file and do callbacks
>>>>>> for any read leases for the file). Deleting VOP_LEASE would break
>>>>>> NFS big time.
>>>>>
>>>>> I think our NQNFS support might have been removed some time ago - I can't
>>>>> see any calls to VOP_LEASE in the code right now. Something like
>>>>> VOP_LEASE
>>>>> would certainly be useful for a hypothetical future NFSv4 server. I
>>>>> believe that samba could use it too for its oplocks feature which appears
>>>>> to be similar to NQNFS's leases and NFSv4's delegations.
>>>>
>>>> So the idea with delegations is that close() doesn't actually release the
>>>> file entirely to make future access cheaper?
>>>>
>>>> My issue with VOP_LEASE is only that there are no in kernel
>>>> implementations of the VOP.  I doubt it is applied regularly in syscalls.
>>>> It also seems odd that it is called without a lock.
>>>>
>>>> Is the intent that the server will trap all accesses to a local vnode in
>>>> order to invalidate the client leases?
>>>
>>> VOP_LEASE is supposed to implemented by a filesystem client.
>>>
>>> For insance, NFS client with NQNFS would implement the VOP_LEASE
>>> and trap those accesses to manage the lease with the remote server.
>>>
>>> The remote server would get "lease RPCs" from the client and manage
>>> the cache appropriately.

So just to be clear, this is required for nfsv4 client but not presently 
used by nfsv4 client?  The vnodes we're calling VOP_LEASE on are actually 
remote files?

>>
>> So why isn't this done within the actual VOP?  If the lease expires
>> between calling VOP_LEASE and vn_lock(), VOP_READ() you have to do that
>> work all over again anyway.
>>
>> I don't yet see why this is in filesystem independent code.  I'm not
>> asserting that it doesn't need to be.  I'd just like to understand it
>> better.
>
> The reason to have it is to reduce code duplication and not to be
> holding the vnode locks while doing the callbacks into the server
> code.
>
> Let me explain, the reason is 2-fold, one for reducing code duplication
> and the other for avoiding holding locks for extended periods.
>
> Consider a local client contending against a remote client for a
> filesystem that supported leases.
>
> Basically, each and every filesytem would have to explicitly do a
> VOP_LEASE at the start of every routine that required notifying the
> server making use of the underlying filesystem.

So this is for the _server_ side and not the client side.  That's what I 
originally asked.  So you want to notify the nfsv4 server code that 
has mounted a local filesystem that you're going to modify or read a file 
locally so it can invalidate the client cache.  Correct?

>
> What you really wind up doing is having a vop_stdlocallease that
> calls into a generic lease manager that does callbacks into any
> server exporting that file.
>
> So, if you move the lease call INTO the VOP_READ/READDIR/WRITE/etc
> you wind up holding vnode locks while doing client communication
> when contending with remote servers.

Ok but doesn't this open a race?

What about:
VOP_LEASE() -> invalidate current remote leases
<- new lease established
vn_lock()
VOP_WRITE()
vn_unlock()

Jeff


>
> -- 
> - Alfred Perlstein
>