All of lore.kernel.org
 help / color / mirror / Atom feed
From: "bfields@fieldses.org" <bfields@fieldses.org>
To: Trond Myklebust <trondmy@primarydata.com>
Cc: "chuck.lever@oracle.com" <chuck.lever@oracle.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1] nfs: Don't increment lock sequence ID after NFS4ERR_MOVED
Date: Tue, 24 Jan 2017 15:31:53 -0500	[thread overview]
Message-ID: <20170124203153.GD20844@fieldses.org> (raw)
In-Reply-To: <1485289414.12087.0.camel@primarydata.com>

On Tue, Jan 24, 2017 at 08:23:36PM +0000, Trond Myklebust wrote:
> On Tue, 2017-01-24 at 14:15 -0500, J. Bruce Fields wrote:
> > On Tue, Jan 24, 2017 at 02:06:16PM -0500, Chuck Lever wrote:
> > > 
> > > > On Jan 23, 2017, at 11:49 AM, bfields@fieldses.org wrote:
> > > > 
> > > > On Mon, Jan 23, 2017 at 10:01:27AM -0500, Chuck Lever wrote:
> > > > > 
> > > > > > On Jan 22, 2017, at 2:04 PM, Chuck Lever <chuck.lever@oracle.
> > > > > > com> wrote:
> > > > > > 
> > > > > > Xuan Qi reports that the Linux NFSv4 client failed to lock a
> > > > > > file
> > > > > > that was migrated. The steps he observed on the wire:
> > > > > > 
> > > > > > 1. The client sent a LOCK request
> > > > > > 2. The server replied NFS4ERR_MOVED
> > > > > > 3. The client switched to the destination server
> > > > > > 4. The client sent the LOCK request again with a bumped
> > > > > >  lock sequence ID
> > > > > > 5. The server rejected the LOCK request with
> > > > > > NFS4ERR_BAD_SEQID
> > > > > 
> > > > > The list of steps could be more clear:
> > > > > 
> > > > > 1. The client sent a LOCK request to the source server
> > > > > 2. The source server replied NFS4ERR_MOVED
> > > > > 3. The client switched to the destination server
> > > > > 4. The client sent the same LOCK request to the destination
> > > > >   server with a bumped lock sequence ID
> > > > > 5. The destination server rejected the LOCK request with
> > > > >   NFS4ERR_BAD_SEQID
> > > > > 
> > > > > 
> > > > > > RFC 3530 section 8.1.5 provides a list of NFS errors which do
> > > > > > not
> > > > > > bump a lock sequence ID.
> > > > > > 
> > > > > > However, RFC 3530 is now obsoleted by RFC 7530. In RFC 7530
> > > > > > section
> > > > > > 9.1.7, this list has been updated by the addition of
> > > > > > NFS4ERR_MOVED.
> > > > 
> > > > I guess we figured the backwards-incompatible change was OK since
> > > > essentially the Solaris server is the first we know of to be
> > > > making real
> > > > use of NFS4ERR_MOVED?
> > > > 
> > > > And probably it's required for the their implementation because
> > > > the old
> > > > server no longer has the ability to update the state once it's
> > > > reached
> > > > the point of returning ERR_MOVED.
> > > > 
> > > > OK, makes sense to me, I think.
> > > 
> > > Hi Bruce-
> > > 
> > > Does this mean you will take this patch, or should
> > > I just add your Reviewed-by: ?
> > 
> > I can take it if nobody objects.  Mind if I append the above to the
> > changelog?  (Just want to document why we think the apparently
> > backwards-incompatible change is OK.)
> > 
> I've already added it to my linux-next branch as a stable patch.

OK, fine by me, dropping.--b.

  reply	other threads:[~2017-01-24 20:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-22 19:04 [PATCH v1] nfs: Don't increment lock sequence ID after NFS4ERR_MOVED Chuck Lever
2017-01-23 15:01 ` Chuck Lever
2017-01-23 16:49   ` J. Bruce Fields
2017-01-24 19:06     ` Chuck Lever
2017-01-24 19:15       ` J. Bruce Fields
2017-01-24 19:31         ` Chuck Lever
2017-01-24 19:41           ` J. Bruce Fields
2017-01-24 19:53             ` J. Bruce Fields
2017-01-24 19:58               ` Chuck Lever
2017-01-24 19:54             ` Chuck Lever
2017-01-24 20:23         ` Trond Myklebust
2017-01-24 20:31           ` bfields [this message]
2017-01-25 19:58           ` Chuck Lever
2017-01-25 20:08             ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170124203153.GD20844@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.