From: Max Matveev <makc@redhat.com>
To: linux-nfs@vger.kernel.org
Subject: NFS/TCP timeout sequence
Date: Thu, 7 Jul 2011 18:11:46 +1000 [thread overview]
Message-ID: <19989.27202.793003.725608@regina.usersys.redhat.com> (raw)
I've had to look at the way NFS/TCP does its timeouts and backoff
and it does not make a lot of sense to me: according to the
following paragram from nfs(5) on Fedora 14 (I'm using Fedora 14
because it has more text then the same page in nfs-utils):
timeo=n The time (in tenths of a second) the NFS client waits
for a response before it retries an NFS request. If this
option is not specified, requests are retried every 60
seconds for NFS over TCP. The NFS client does not per‐
form any kind of timeout backoff for NFS over TCP.
but if I try the mount with timeo=20,retrans=7 then I'm getting
retransmits which are 2, 4, 6, 8, 2, 4, 6, 8 seconds apart, i.e.
there is a) linear backoff and b) the backoff is not long enough to
let the complete sequence of 7 retransmits run its course.
This is happening because to_maxval for NFS_TCP is too short to
accomodate the linear backoff - we need to either increase the
to_maxval to something like:
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -606,7 +606,8 @@ static void nfs_init_timeout_values(struct rpc_timeout *to,
if (to->to_initval > NFS_MAX_TCP_TIMEOUT)
to->to_initval = NFS_MAX_TCP_TIMEOUT;
to->to_increment = to->to_initval;
- to->to_maxval = to->to_initval + (to->to_increment * to->to_retries);
+ to->to_maxval = to->to_increment * (to->to_retries + 1)
+ * (to->to_retries + 2) / 2;
if (to->to_maxval > NFS_MAX_TCP_TIMEOUT)
to->to_maxval = NFS_MAX_TCP_TIMEOUT;
if (to->to_maxval < to->to_initval)
or don't do the linear backoff
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -546,7 +546,7 @@ static void xprt_reset_majortimeo(struct rpc_rqst *req)
if (to->to_exponential)
req->rq_majortimeo <<= to->to_retries;
else
- req->rq_majortimeo += to->to_increment * to->to_retries;
+ req->rq_majortimeo += to->to_increment;
if (req->rq_majortimeo > to->to_maxval || req->rq_majortimeo == 0)
req->rq_majortimeo = to->to_maxval;
req->rq_majortimeo += jiffies;
max
next reply other threads:[~2011-07-07 8:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 8:11 Max Matveev [this message]
2011-07-07 13:47 ` NFS/TCP timeout sequence Trond Myklebust
2011-07-07 14:04 ` Chuck Lever
2011-07-07 14:16 ` Trond Myklebust
2011-07-07 14:44 ` Chuck Lever
2011-07-07 14:59 ` Trond Myklebust
2011-08-04 5:54 ` Max Matveev
2011-08-04 5:42 ` [PATCH] NFS: allow enough time for timeouts to run Max Matveev
2011-08-04 5:47 ` [PATCH] Update nfs(5) manpage - timeo for NFS/TCP Max Matveev
2011-08-04 12:04 ` Jim Rees
2011-08-05 0:57 ` Max Matveev
2011-08-05 1:39 ` Jim Rees
2011-08-05 2:14 ` Max Matveev
2011-07-08 6:05 ` NFS/TCP timeout sequence Max Matveev
2011-07-08 0:20 ` Max Matveev
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=19989.27202.793003.725608@regina.usersys.redhat.com \
--to=makc@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).