VOP_LEASE

[Alfred Perlstein]

* 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 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.

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.

-- 
- Alfred Perlstein