Date: Tue, 15 Apr 2008 10:02:52 -0400 From: Stephan Uphoff <ups@freebsd.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: Kirk McKusick <mckusick@mckusick.com>, arch@freebsd.org Subject: Re: [SPAM] Re: VOP_LEASE Message-ID: <4804B58C.1010403@freebsd.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
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. I remember looking at VOP_LEASE quite a bit some time ago and came to the same conclusion as Jeff. It is just racy and not maintained. > > 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. > Installing the filters in Solaris seems a bit racy as I did not notice waiting for/draining existing operations. I believe our locking approach ( locking is exported to VFS - something that I personally don't like) may fix this as we can hold a lock while installing a filter. Most VFS exported functions are called with a lock held and the others may be safe. This being said we should talk more about what we don't like about the current VFS before making it even harder to replace. Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4804B58C.1010403>