From: Chris Siebenmann <cks@cs.toronto.edu>
To: linux-nfs@vger.kernel.org
Cc: cks@cs.toronto.edu
Subject: nfsiostat has a confusion about XPRT-related stats for at least NFSv3
Date: Fri, 21 Sep 2018 16:03:55 -0400 [thread overview]
Message-ID: <20180921200355.6A25C322B90@apps1.cs.toronto.edu> (raw)
The nfsiostat program from nfs-utils currently reports and uses
XPRT related statistics on a per-mountpoint basis (it uses them for the
sort order of -s and thus potentially for -l's limit). This is natural,
since /proc/self/mountstats reports them on a per-mountstat basis.
Unfortunately this is not actually accurate or correct. An XPRT can be
shared between mount points from the same NFS server (at least for NFS
v3). On our Ubuntu NFS clients, we typically see a single XPRT being
shared by all NFS mounts from a single fileserver, which can be over a
hundred mounts. Naturally these NFS mounts usually have wildly varying
levels of activity. As a result, nfsiostat's use of XPRT-based stats
often presents a highly misleading picture of per-mount activity and
(for us) makes both -s and -l into useless options.
I'm not sure that there's any simple fix for this for nfsiostat. This
assumption about what the per-XPRT stats means strikes me as deeply
embedded into the structure of the code and the information it presents.
Fixing it may well call for a rethink of the information that nfsiostat
presents and how it gets presented, especially since per-XPRT information
might be useful to have by itself (which would probably call for another
output mode). This doesn't look like a simple patch, it looks like a
significant rewrite of portions of the current code, one driven by a
vision of what people want and what the output should be.
- cks
reply other threads:[~2018-09-22 1:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20180921200355.6A25C322B90@apps1.cs.toronto.edu \
--to=cks@cs.toronto.edu \
--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).