From owner-svn-src-head@FreeBSD.ORG Wed May 20 15:36:42 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13DF1065672; Wed, 20 May 2009 15:36:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 47D9D8FC15; Wed, 20 May 2009 15:36:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADe5E0qDaFvK/2dsb2JhbADPL4QIBQ X-IronPort-AV: E=Sophos;i="4.41,221,1241409600"; d="scan'208";a="33945118" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 20 May 2009 11:07:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 2C726109C271; Wed, 20 May 2009 11:07:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hcfx62-OmMmy; Wed, 20 May 2009 11:07:13 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 6A0F6109C257; Wed, 20 May 2009 11:07:13 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n4KF7rE21826; Wed, 20 May 2009 11:07:53 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 20 May 2009 11:07:53 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Doug Rabson In-Reply-To: Message-ID: References: <200905171933.n4HJXmC0037587@svn.freebsd.org> <8ECF61A0-AFE1-4320-B0AA-2216C268A921@rabson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, Rick Macklem , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r192256 - head/sys/fs/nfsserver X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 15:36:43 -0000 On Wed, 20 May 2009, Doug Rabson wrote: > Thinking about this for a few more minutes, I think you probably want to > allocate a sysid for each client and then for each lock_owner of that client > allocate a 'pid'. The value doesn't have to be a process identifier but it > does have to allow different lock owners from the same client to be > distinguished. > Why do they need to be distinguished? The nfsv4 state subsystem handles all conflicts between them, so they are just "nfsv4 locks". An nfsv4 lockowner is a ClientID + up to 1024 bytes of opaque name and it might not persist in the server beyond the point where no locks are held and the associated OpenOwner no longer has any Opens. After this, the same lockowner could be "re-incarnated" (ie. create a new state data structure in the server with the same ClientID + up to 1024 bytes) when the client chooses to do more locking on it. If a pid is generated sequentially, this second re-incarnation would end up with a different pid although it is the same lockowner. (To ensure this doesn't happen, the server would have to hold onto the lockowner state structure "forever" and that obviously isn't practical.) Or a pid could be a 32bit checksum on the ClientID + up to 1024 bytes instead of sequential assignment. In that case the re-incarnation would get the same pid, but it wouldn't be guaranteed to be unique across all different lockowners. As such, the most an assigned pid could be is a "hint" that the lockowner is different/same. Is there some benefit to this over "held by nfsv4", which is what using one tuple gives you? > You probably also want to record locks in the local lock manager on the > client. In NLM, I use a different range of sysids starting at 0x100000 for > this. This lets you do lock recovery after a server restart by asking the > local lock manager to enumerate locks for the right sysid. > The lock state all lives in the nfsv4 client (some associated with a delegation and assigned locally, the rest tied to an associated Open) with the "up to 1024 byte" owner names generated by the client, etc. Maintaining the rather complex relationship between Opens (with Openowners) and their associated locks is probably the "most interesting" part of implementing nfsv4. Then you must recover the locks, maintaining that relationship. (The relationship is established via the open_to_lock_owner case of the Lock Op.) The recovery code uses client side data structures that reflect the open/lock relationship. The lock manager wouldn't be able to provide that information and I think there would be little gained by trying to make the major modifications that would be required so that it could do so. > On 20 May 2009, at 09:26, Doug Rabson wrote: > >> This is incorrect. A sysid of zero is reserved for local locks on local >> filesystems. You need to allocate a sysid when the client is created and it >> needs to not conflict with the sysids used by NLM. I suggest adding a >> function to nlm_prot_impl.c to return the next available sysid (and bump >> the counter). >> Ok, when I looked at the code, l_sysid only seemed to be used when F_REMOTE is set, so I didn't realize that l_sysid == 0 was reserved for local locks. I'll look at what you suggest and send you an nlm patch for review. rick