VOP_LEASE
Doug Rabson
dfr at rabson.org
Sun Apr 13 08:59:13 UTC 2008
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.
More information about the freebsd-arch
mailing list