From: "J. Bruce Fields" <bfields@fieldses.org>
To: Sander Klein <roedie@roedie.nl>
Cc: linux-nfs@vger.kernel.org
Subject: Re: rpc.mountd high cpu usage
Date: Thu, 12 Dec 2013 16:22:13 -0500 [thread overview]
Message-ID: <20131212212213.GC13467@fieldses.org> (raw)
In-Reply-To: <3e92cb841fa81d6a16f3d471cdd8bb20@roedie.nl>
On Thu, Dec 12, 2013 at 05:42:44PM +0100, Sander Klein wrote:
> On , J. Bruce Fields wrote:
> >That sounds like somewhat of an extreme setup, and I suspect the
> >current
> >behavior is by design, but I agree that we should fix it. I'm not
> >volunteering for now....
>
> Ow dear, I never thought that this would classified as an extreme
> setup :-) .
Eh, maybe it's not.
> >I think what happens is that exportfs flushes the kernel's export cache
> >at which point every use of an uncached export triggers an upcall to
> >mountd. That upcall is probably visible in the strace as a read of a
> >file descriptor associated with /proc/net/sunrpc/nfsd.fh/content.
> >
> >That upcall is handled by nfs-utils/utils/mountd/cache.c:nfsd_fh(),
> >which is given a filehandle fragment identifying the filesystem in
> >question and has to match it to an export.
> >
> >That's done by match_fsid(). Which does do a stat of the export path,
> >but not of all the devices.... That's probably happening in one of the
> >libblkid calls in uuid_by_path()? I wonder if there's something wrong
> >with libblkid configuration or with the way we're using it?
>
> Is there any way I can help getting this fixed? My coding skills are
> limited but I am very willing to help in any way I can.
I wonder if ltrace could help determine if libblkid is where most of
those stat's are coming from (and if so, which calls)?
May also be worth reading up on libblkid (man libblkid, etc.) and
checking your configuration to make sure there's nothing obvious broken
there. (If so, maybe the libblkid commandline tools would exhibit the
same problem?)
--b.
next prev parent reply other threads:[~2013-12-12 21:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 10:13 rpc.mountd high cpu usage Sander Klein
2013-12-12 15:46 ` J. Bruce Fields
2013-12-12 16:42 ` Sander Klein
2013-12-12 21:22 ` J. Bruce Fields [this message]
2013-12-13 19:32 ` Sander Klein
2013-12-19 17:09 ` J. Bruce Fields
2013-12-23 11:01 ` Sander Klein
2014-01-06 11:18 ` Karel Zak
2014-01-06 16:20 ` Sander Klein
2014-01-06 16:31 ` Karel Zak
2014-01-06 21:25 ` J. Bruce Fields
2014-01-07 19:55 ` Sander Klein
2014-01-07 20:49 ` J. Bruce Fields
2014-01-07 21:01 ` Steve Dickson
2014-01-08 9:09 ` Sander Klein
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=20131212212213.GC13467@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=roedie@roedie.nl \
/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).