Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: Need help debugging NFS issues new to 4.20 kernel
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <B730E8AE-AFA3-4CE7-9103-FCCC35C37EDD@redhat.com>
Date:   Fri, 8 Feb 2019 10:19:40 -0500
Cc:     Jason Tibbitts <tibbs@math.uh.edu>,
        Trond Myklebust <trondmy@hammerspace.com>,
        Anna Schumaker <Anna.Schumaker@netapp.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C8B2CA6-0254-44B2-B5A8-A2A9E0C042E9@oracle.com>
References: <ufaimyearlx.fsf@epithumia.math.uh.edu>
 <eff194a660ce562753d0112cdf6b1aacc5aa5dfb.camel@hammerspace.com>
 <ufak1isms71.fsf@epithumia.math.uh.edu>
 <87ftt2cdeq.fsf@hippogriff.math.uh.edu>
 <FC712F54-5A7A-436D-B076-936B29C013F4@redhat.com>
 <87imxwab12.fsf@hippogriff.math.uh.edu>
 <662CE7B3-235E-4E2D-9C8C-0F6233F3085F@redhat.com>
 <87d0o3aadg.fsf@hippogriff.math.uh.edu>
 <B730E8AE-AFA3-4CE7-9103-FCCC35C37EDD@redhat.com>
To:     Benjamin Coddington <bcodding@redhat.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Feb 8, 2019, at 7:01 AM, Benjamin Coddington <bcodding@redhat.com> =
wrote:
>=20
>=20
> On 7 Feb 2019, at 10:25, Jason Tibbitts wrote:
>=20
>>>>>>> "BC" =3D=3D Benjamin Coddington <bcodding@redhat.com> writes:
>>=20
>> BC> -10063 is -NFS4ERR_SEQ_MISORDERED.. I wonder why the
>> BC> trace_nfs4_sequence_done() in nfs41_sequence_process() isn't =
showing
>> BC> up in the trace?  Ah.. my fault - add "nfs4:*" to the set_events.
>>=20
>> OK, attached is another trace.  Here's the same sequence I snipped
>> previously:
>=20
> So the client is calling SEQ over and over.. xs_stream_read_data sees
> -EAGAIN.. I'm not an expert here, and not seeing what's going wrong.

<wag>

The server is returning SEQ_MISORDERED to a singleton SEQUENCE.
That suggests the client is trying to re-establish its lease but is
sending a slot nr the server doesn't recognize for the virtual slot
used for this purpose. Could be a problem on either side, and I
don't know enough to say how this loop could have started.

</wag>


> Hmm.. commit c443305529d1d3d3bee0d68fdd14ae89835e091f changed
> xs_read_stream_reply() to return recv.copied instead of "ret" to
> xprt_complete_rqst()..
>=20
> You could try reverting that commit and see if the problem goes away..
>=20
> Ben

--
Chuck Lever