VOP_LEASE

[Doug Rabson]

On 13 Apr 2008, at 09:41, Jeff Roberson wrote:

> On Sun, 13 Apr 2008, Doug Rabson wrote:
>
>>
>> On 13 Apr 2008, at 00:15, Jeff Roberson 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?
>>
>> I'm working from memory here (too lazy to checkout an old tree). I  
>> seem to remember that the way this worked is that when an NQNFS  
>> server granted a lease to a remote client, it arranged things so  
>> that any local filesystem access to the leased file would first  
>> evict the remote leaseholder. While the remote client has a valid  
>> lease, it is free to agressively cache locally as long as it  
>> flushes write to the server on eviction. The implementation was  
>> quite intrusive on the server. I can't quite remember where  
>> VOP_LEASE came in and the documentation is useless.
>
> I discussed it more with alfred.  I don't intend to remove VOP_LEASE  
> since there may be some valid use for it.  We just haven't had any  
> code in at least a decade that made use of it so I thought it was  
> prime for axing.
>
> I believe that calling the VOP without a lock makes it prone to  
> races which make it minimally useful.  However I'm willing to  
> reserve judgement until some consumer actually shows up.
>
> Sun doesn't seem to have a VOP_LEASE or similar in Solaris.  They  
> actually seem to install a kind of filter on vfs and vnode  
> operations and monitor there.  Their filters do more than VOP_LEASE  
> does and operate a bit like the vop_*_pre and post hooks I added for  
> debugging which now have been turned on all the time.  It might be  
> cleaner if we implemented the lease notification in these hooks  
> instead.

That sounds reasonable. Actually one good reason for removing  
VOP_LEASE as it currently stands would be that there is no  
specification and no implementation to derive a specification from.