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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
