From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Jason Tibbitts" <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:   Wed, 06 Feb 2019 07:05:49 -0500
Message-ID: <FC712F54-5A7A-436D-B076-936B29C013F4@redhat.com>
In-Reply-To: <87ftt2cdeq.fsf@hippogriff.math.uh.edu>
References: <ufaimyearlx.fsf@epithumia.math.uh.edu>
 <eff194a660ce562753d0112cdf6b1aacc5aa5dfb.camel@hammerspace.com>
 <ufak1isms71.fsf@epithumia.math.uh.edu>
 <87ftt2cdeq.fsf@hippogriff.math.uh.edu>
MIME-Version: 1.0
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On 5 Feb 2019, at 13:12, Jason Tibbitts wrote:

>>>>>> "JLT" == Jason L Tibbitts <tibbs@math.uh.edu> writes:
>
> JLT> I wonder, though; is that likely to be the root of the problem I'm
> JLT> seeing?  The commit description talks about this as a performance
> JLT> regression, but I'm seeing a complete loss of NFS functionality.
>
> It turns out that 4.20.6 (which has the patch in question) does not
> appear to solve my issue.  At least, I've still had a few complete NFS
> hangups on machines running 4.20.6 though I haven't had a chance to
> closely inspect one yet.
>
> As before, any hints about how I could best debug this issue would be
> appreciated.

Hi Jason, you can enable the NFS and SUNRPC tracepoints to get a better idea
of what the client was doing right before the hang or what the client is
trying to do during the hang:

echo "sunrpc:*" >>  /sys/kernel/debug/tracing/set_event
echo "nfs:*" >> /sys/kernel/debug/tracing/set_event

Examine or provide the contents of /sys/kernel/debug/tracing/trace.

Ben