From: "J. Bruce Fields" <bfields@fieldses.org>
To: Joschi Brauchle <joschi.brauchle@tum.de>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: nfsd4: utime sometimes takes 40+ seconds to return (but on SLES11SP3 with kernel 3.0.82)
Date: Tue, 17 Sep 2013 09:31:22 -0400 [thread overview]
Message-ID: <20130917133122.GA32333@fieldses.org> (raw)
In-Reply-To: <5232F7DF.5080204@tum.de>
On Fri, Sep 13, 2013 at 01:32:47PM +0200, Joschi Brauchle wrote:
> After three days of testing the NFS server *with* rpc.gssd running
> with multiple NFS clients, we made the following observation:
>
> The hangs on "utime()" calls have **not** disappeared by simply starting
> rpc.gssd on the server. The problem persists!
>
> I seems like
> a) on machines that are already connected to the NFS server when
> rpc.gssd is started, the hangs dissappear *mostly*. That is, running
> the utime-test-program causes about 1 spurious hang every 10
> minutes.
> b) on machines that connect to the NFS server at a later time
> (rpc.gssd already running on the server), the hangs seem appear
> every "utime()" call.
>
> The server emits spurious "RPC: AUTH_GSS upcall timed out. Please
> check user daemon is running." messages, although rpc.gssd is
> running. This may or may not be related, as this message may also be
> caused by clients where the root user access NFS shared with a
> "host/<hostname>" credential.
>
> The output of "rpcdebug -m nfsd -s proc" to pastebin.com. Get it with
> pbget http://pastebin.com/N34r5kWE
>
> The IP of the newly connected host is: 192.168.109.154 and its
> SETCLIENTID call was logged. Unfortunately, this log was created
> while *many* other NFS clients were connected, hence it may not be
> too useful.
>
> I'd be very grateful for any help or instructions on
> debugging/fixing this problem.
NFSv4.0 callbacks have just broken for a while, I think; I'll look into
it.
Meanwhile you should be able to work around this by disabling leases on
the server (so, "echo 0 >/proc/sys/fs/leases-enable" before starting
nfsd).
(Or if you're more daring and running a very recent upstream kernel,
switching to NFSv4.1 should work too.)
--b.
prev parent reply other threads:[~2013-09-17 13:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 18:49 nfsd4: utime sometimes takes 40+ seconds to return (but on SLES11SP3 with kernel 3.0.82) Joschi Brauchle
2013-09-10 20:35 ` J. Bruce Fields
2013-09-10 21:48 ` Joschi Brauchle
2013-09-10 21:55 ` J. Bruce Fields
2013-09-10 22:08 ` Joschi Brauchle
2013-09-10 22:11 ` J. Bruce Fields
2013-09-13 11:32 ` Joschi Brauchle
2013-09-17 13:31 ` J. Bruce Fields [this message]
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=20130917133122.GA32333@fieldses.org \
--to=bfields@fieldses.org \
--cc=joschi.brauchle@tum.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.