From owner-freebsd-arch@FreeBSD.ORG Sun Apr 13 08:59:13 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0DB2106566C for ; Sun, 13 Apr 2008 08:59:13 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (mail.rabson.org [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 249CF8FC22 for ; Sun, 13 Apr 2008 08:59:13 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2002:50b1:e8f2:1:21b:63ff:feb8:5abc] (unknown [IPv6:2002:50b1:e8f2:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 3773B3FB4; Sun, 13 Apr 2008 09:59:12 +0100 (BST) Message-Id: <579895DC-DE8D-4DED-8E0B-CFCC73032A6A@rabson.org> From: Doug Rabson To: Jeff Roberson In-Reply-To: <20080412222458.B959@desktop> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 13 Apr 2008 09:59:11 +0100 References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> <20080412131017.S43186@desktop> <20080412222458.B959@desktop> X-Mailer: Apple Mail (2.919.2) Cc: Kirk McKusick , arch@freebsd.org Subject: Re: VOP_LEASE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2008 08:59:13 -0000 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 >>>>>> 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.