From owner-freebsd-arch@FreeBSD.ORG Sun Apr 13 08:41:28 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 889F6106564A for ; Sun, 13 Apr 2008 08:41:28 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 610068FC1F for ; Sun, 13 Apr 2008 08:41:28 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id k17so1336249waf.3 for ; Sun, 13 Apr 2008 01:41:28 -0700 (PDT) Received: by 10.114.124.12 with SMTP id w12mr2233594wac.210.1208076087815; Sun, 13 Apr 2008 01:41:27 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id k37sm8707412waf.55.2008.04.13.01.41.26 (version=SSLv3 cipher=OTHER); Sun, 13 Apr 2008 01:41:27 -0700 (PDT) Date: Sat, 12 Apr 2008 22:41:44 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Doug Rabson In-Reply-To: Message-ID: <20080412222458.B959@desktop> References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> <20080412131017.S43186@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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:41:28 -0000 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. Cheers, Jeff