linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Benjamin Coddington" <bcodding@redhat.com>
To: "Jason L Tibbitts III" <tibbs@math.uh.edu>
Cc: "Trond Myklebust" <trondmy@hammerspace.com>,
	Anna.Schumaker@netapp.com, linux-nfs@vger.kernel.org,
	Chuck.Lever@oracle.com
Subject: Re: Need help debugging NFS issues new to 4.20 kernel
Date: Mon, 25 Feb 2019 18:15:26 -0500	[thread overview]
Message-ID: <DADB4AE9-5C48-4D31-AAC9-D0C78BDA4442@redhat.com> (raw)
In-Reply-To: <ufa36obbrje.fsf@epithumia.math.uh.edu>

Hi Jason,

It looks like Trond has this patch on his "linux-next" and on his 
"testing" branch:

http://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=shortlog;h=refs/heads/linux-next

commit 3453d5708b33efe76f40eca1c0ed60923094b971
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Jun 20 17:53:34 2018 -0400

     NFSv4.1: Avoid false retries when RPC calls are interrupted

     A 'false retry' in NFSv4.1 occurs when the client attempts to 
transmit a
     new RPC call using a slot+sequence number combination that 
references an
     already cached one. Currently, the Linux NFS client will do this if 
a
     user process interrupts an RPC call that is in progress.
     The problem with doing so is that we defeat the main mechanism used 
by
     the server to differentiate between a new call and a replayed one. 
Even
     if the server is able to perfectly cache the arguments of the old 
call,
     it cannot know if the client intended to replay or send a new call.

     The obvious fix is to bump the sequence number pre-emptively if an
     RPC call is interrupted, but in order to deal with the corner cases
     where the interrupted call is not actually received and processed 
by
     the server, we need to interpret the error NFS4ERR_SEQ_MISORDERED
     as a sign that we need to either wait or locate a correct sequence
     number that lies between the value we sent, and the last value that
     was acked by a SEQUENCE call on that slot.

     Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
     Tested-by: Jason Tibbitts <tibbs@math.uh.edu>

That's usually a good sign that he will include it in a pull request 
when the 5.1 merge window opens.

Anna and Trond trade off sending patches for each linux release, this 
time around Trond will send them.

Without having to take any further steps I expect this will land in 
mainline for 5.1, and fedora will eventually pick it up.

Ben

On 25 Feb 2019, at 14:24, Jason L Tibbitts III wrote:

> So I've now running this patch ("NFSv4.1: Avoid false retries when RPC
> calls are interrupted") for several days with no hangs at all and no
> other regressions noted.  What would the next step be?  Will this be
> sent upstream?  I'm not sure how to check if this is queued for
> submission in someone's tree.
>
> I doubt there is anything I can do to help the process but please let 
> me
> know if there is.
>
>  - J<

  reply	other threads:[~2019-02-25 23:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 17:32 Need help debugging NFS issues new to 4.20 kernel Jason L Tibbitts III
2019-01-24 19:28 ` Jason L Tibbitts III
2019-01-24 19:58 ` Trond Myklebust
2019-01-25 19:13   ` Schumaker, Anna
2019-01-26 17:59     ` Sasha Levin
2019-01-25 19:51   ` Jason L Tibbitts III
2019-02-05 18:12     ` Jason Tibbitts
2019-02-06 12:05       ` Benjamin Coddington
     [not found]         ` <87imxwab12.fsf@hippogriff.math.uh.edu>
2019-02-07 11:13           ` Benjamin Coddington
     [not found]             ` <87d0o3aadg.fsf@hippogriff.math.uh.edu>
2019-02-08 12:01               ` Benjamin Coddington
2019-02-08 15:19                 ` Chuck Lever
2019-02-08 17:17                   ` Jason L Tibbitts III
2019-02-15 20:33                 ` Jason L Tibbitts III
2019-02-16 14:46                   ` Trond Myklebust
2019-02-20  2:13                     ` Jason L Tibbitts III
2019-02-20 15:25                     ` Jason L Tibbitts III
2019-02-20 15:37                       ` Trond Myklebust
2019-02-20 15:39                         ` Chuck Lever
2019-02-20 15:41                         ` Trond Myklebust
2019-02-21 18:19                           ` Jason L Tibbitts III
2019-02-25 19:24                             ` Jason L Tibbitts III
2019-02-25 23:15                               ` Benjamin Coddington [this message]
2019-02-20 16:25                         ` Jason L Tibbitts III
2019-02-20 16:45                           ` Trond Myklebust
2019-02-20 16:49                             ` Jason L Tibbitts III

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=DADB4AE9-5C48-4D31-AAC9-D0C78BDA4442@redhat.com \
    --to=bcodding@redhat.com \
    --cc=Anna.Schumaker@netapp.com \
    --cc=Chuck.Lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tibbs@math.uh.edu \
    --cc=trondmy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).