VOP_LEASE

[Jeff Roberson]

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.

Cheers,
Jeff