Date: Sun, 13 Apr 2008 09:59:11 +0100 From: Doug Rabson <dfr@rabson.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: Kirk McKusick <mckusick@mckusick.com>, arch@freebsd.org Subject: Re: VOP_LEASE Message-ID: <579895DC-DE8D-4DED-8E0B-CFCC73032A6A@rabson.org> In-Reply-To: <20080412222458.B959@desktop> References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> <20080412131017.S43186@desktop> <DA20A395-69A0-4299-9FEF-F8382797B08E@rabson.org> <20080412222458.B959@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
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@jroberson.net> >>>>>> To: arch@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?579895DC-DE8D-4DED-8E0B-CFCC73032A6A>