From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from acsinet15.oracle.com ([141.146.126.227]:42869 "EHLO acsinet15.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934441Ab2DLPyL convert rfc822-to-8bit (ORCPT ); Thu, 12 Apr 2012 11:54:11 -0400 Subject: Re: global openowner_id and lockowner_id Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Chuck Lever In-Reply-To: <1334245818.2237.55.camel@lade.trondhjem.org> Date: Thu, 12 Apr 2012 11:54:04 -0400 Cc: Linux NFS Mailing List Message-Id: <7212EB20-16EC-475E-993E-3F244C621AB0@oracle.com> References: <58E57AF8-1636-4017-93C0-8520488ED866@oracle.com> <1334245818.2237.55.camel@lade.trondhjem.org> To: "Myklebust, Trond" Sender: linux-nfs-owner@vger.kernel.org List-ID: On Apr 12, 2012, at 11:50 AM, Myklebust, Trond wrote: > On Thu, 2012-04-12 at 11:42 -0400, Chuck Lever wrote: >> Hi- >> >> Changing the SETCLIENTID boot verifier so it is global for the whole client exposes a problem with how we allocate state owners. >> >> A quick umount / mount sequence destroys all state on the client. But since the client now always uses the same boot verifier and nfs_client_id4 string, the server no longer recognizes a client reboot. FOr a fresh mount, the client may perform a SETCLIENTID, but it is treated as a callback update (state is not purged) if the client's lease has not yet expired. >> >> Our state owners are generated from a pair of ida structures in the nfs_server for that mount. They always start from zero after a mount operation. Likewise, the sequence IDs for these state owners are also reset by umount / mount. Note that each mount point gets a fresh nfs_server, so these structures are not retained across umount / mount. >> >> This means umount / mount with no lease expiry starts to re-play state owners with reset sequence IDs. Servers don't really care for that behavior. I have a test case that reliably gets a BAD_SEQID error from a server after a quick umount / mount followed by a single file creation. >> >> Now that we are about to switch to using more-or-less global SETCLIENTID boot verifiers, it seems to me that we really want a global openowner_id and lockowner_id as well. >> >> The performance impact of such a change might be acceptable because we cache and reuse state owners now. >> >> Thoughts? > > That's a definite server bug. If the client holds no open state, then it > is allowed to forget the open owner and start the sequence id from 0 > again. It is not required to remember sequence ids for open owners that > aren't in use. > > Our current client could easily trigger this bug even without a > umount/mount. The client is holding open state. Here's the exact reproducer on my modified client: 1. mount server:/export /mnt 2. touch /mnt/newfile 3. umount /mnt 4. mount server:/export /mnt 5. touch /mnt/newfile2 Step 5 causes the client to replay an open owner with a reset sequence ID, and the server replies BAD_SEQID. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com