Date: Sat, 12 Apr 2008 22:41:44 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Doug Rabson <dfr@rabson.org> Cc: Kirk McKusick <mckusick@mckusick.com>, arch@freebsd.org Subject: Re: VOP_LEASE Message-ID: <20080412222458.B959@desktop> In-Reply-To: <DA20A395-69A0-4299-9FEF-F8382797B08E@rabson.org> References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> <20080412131017.S43186@desktop> <DA20A395-69A0-4299-9FEF-F8382797B08E@rabson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Cheers, Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080412222458.B959>