From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Dave Wysochanski <dwysocha@redhat.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 3/3] SUNRPC: Count ops completing with tk_status < 0
Date: Tue, 4 Jun 2019 10:45:35 -0400 [thread overview]
Message-ID: <20190604144535.GA19422@fieldses.org> (raw)
In-Reply-To: <5CE8A68E-F5C2-4321-8F57-451F5E5AF789@oracle.com>
On Mon, Jun 03, 2019 at 02:56:29PM -0400, Chuck Lever wrote:
> > On Jun 3, 2019, at 2:53 PM, Dave Wysochanski <dwysocha@redhat.com> wrote:
> > On Fri, 2019-05-31 at 09:25 -0400, Chuck Lever wrote:
> >>> On May 30, 2019, at 6:33 PM, Bruce Fields <bfields@fieldses.org>
> >>> wrote:
> >>> On Thu, May 30, 2019 at 06:19:54PM -0400, Chuck Lever wrote:
> >>>> We now have trace points that can do that too.
> >>>
> >>> You mean, that can report every error (and its value)?
> >>
> >> Yes, the nfs_xdr_status trace point reports the error by value and
> >> symbolic name.
> >
> > The tracepoint is very useful I agree. I don't think it will show:
> > a) the mount
> > b) the opcode
> >
> > Or am I mistaken and there's a way to get those with a filter or
> > another tracepoint?
>
> The opcode can be exposed by another trace point, but the link between
> the two trace points is tenuous and could be improved.
>
> I don't believe any of the NFS trace points expose the mount. My testing
> is largely on a single mount so my imagination stopped there.
Dumb question: is it possible to add more fields to tracepoints without
breaking some kind of backwards compatibility?
I wonder if adding, say, an xid and an xprt pointer to tracepoints when
available would help with this kind of thing.
In any case, I think Dave's stats will still be handy if only because
they're on all the time.
--b.
next prev parent reply other threads:[~2019-06-04 14:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 20:13 [PATCH 1/3] SUNRPC: Move call to rpc_count_iostats before rpc_call_done Dave Wysochanski
2019-05-23 20:13 ` [PATCH 2/3] SUNRPC: Use proper printk specifiers for unsigned long long Dave Wysochanski
2019-05-23 20:13 ` [PATCH 3/3] SUNRPC: Count ops completing with tk_status < 0 Dave Wysochanski
2019-05-30 21:38 ` J. Bruce Fields
2019-05-30 22:19 ` Chuck Lever
2019-05-30 22:33 ` Bruce Fields
2019-05-31 13:25 ` Chuck Lever
2019-06-03 18:53 ` Dave Wysochanski
2019-06-03 18:56 ` Chuck Lever
2019-06-03 19:05 ` Dave Wysochanski
2019-06-03 19:08 ` Chuck Lever
2019-06-04 14:45 ` Bruce Fields [this message]
2019-06-04 14:56 ` Trond Myklebust
2019-06-07 14:27 ` Dave Wysochanski
2019-05-31 0:17 ` David Wysochanski
2019-05-23 20:13 ` [PATCH] mountstats: add per-op error counts for mountstats command Dave Wysochanski
2019-05-23 20:33 ` [PATCH v2] " Dave Wysochanski
2019-06-03 14:31 ` Steve Dickson
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=20190604144535.GA19422@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=dwysocha@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/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).