All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Talpey <tom@talpey.com>
To: Olga Kornievskaia <aglo@umich.edu>,
	Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: once again problems with interrupted slots
Date: Fri, 5 Jun 2020 08:06:14 -0400	[thread overview]
Message-ID: <13bed646-39b7-197e-ff90-85f8af10d93c@talpey.com> (raw)
In-Reply-To: <CAN-5tyFCotATeYVR0J1B_UaxhXYBDhp21LbFEzZtLYmgN_i+hg@mail.gmail.com>

On 6/4/2020 5:21 PM, Olga Kornievskaia wrote:
> Hi Trond,
> 
> There is a problem with interrupted slots (yet again).
> 
> We send an operation to the server and it gets interrupted by the a signal.
> 
> We used to send a sole SEQUENCE to remove the problem of having real
> operation get an out of the cache reply and failing. Now we are not
> doing it again (since 3453d5708 NFSv4.1: Avoid false retries when RPC
> calls are interrupted"). So the problem is
> 
> We bump the sequence on the next use of the slot, and get SEQ_MISORDERED.

Misordered? It sounds like the client isn't managing the sequence
number, or perhaps the server never saw the original request, and
is being overly strict.

> We decrement the number back to the interrupted operation. This gets
> us a reply out of the cache. We again fail with REMOTE EIO error.

Ew. The client *decrements* the sequence?

Tom.

> Going back to the commit's message. I don't see the logic that the
> server can't tell if this is a new call or the old one. We used to
> send a lone SEQUENCE as a way to protect reuse of slot by a normal
> operation. An interrupted slot couldn't have been another SEQUENCE. So
> I don't see how the server can't tell a difference between SEQUENCE
> and any other operations.
> 
> 

  reply	other threads:[~2020-06-05 12:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04 21:21 once again problems with interrupted slots Olga Kornievskaia
2020-06-05 12:06 ` Tom Talpey [this message]
2020-06-05 13:24   ` Olga Kornievskaia
2020-06-05 13:48     ` Tom Talpey
2020-06-05 15:30       ` Olga Kornievskaia
2020-06-06  1:03         ` Tom Talpey
2020-06-09 18:29     ` 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=13bed646-39b7-197e-ff90-85f8af10d93c@talpey.com \
    --to=tom@talpey.com \
    --cc=aglo@umich.edu \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@hammerspace.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.