NFS/TCP does linear backoff then retransmiting - the manpage
was mistakenly asserting the "no backoff" theory.
Signed-off-by: Max Matveev <[email protected]>
Signed-off-by: Jim Rees <[email protected]>
---
utils/mount/nfs.man | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index be91a25..ff0ed60 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -113,12 +113,16 @@ option may mitigate some of the risks of using the
option.
.TP 1.5i
.BI 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 perform any kind of timeout backoff
-for NFS over TCP.
+The time in deciseconds (tenths of a second) the NFS client waits for a
+response before it retries an NFS request.
+.IP
+For NFS over TCP the default
+.B timeo
+value is 600 (60 seconds).
+The NFS client performs linear backoff: After each retransmission the
+timeout is increased by
+.BR timeo
+up to the maximum of 600 seconds.
.IP
However, for NFS over UDP, the client uses an adaptive
algorithm to estimate an appropriate timeout value for frequently used
--
1.7.4.4
On Fri, 5 Aug 2011 08:40:15 -0400, Jim Rees wrote:
rees> Max Matveev wrote:
rees> NFS/TCP does linear backoff then retransmiting - the manpage
rees> was mistakenly asserting the "no backoff" theory.
rees> Actually, now that I made you change the wording, I think the original
rees> wording was correct. "Backoff" refers to an increase in the interval
rees> between retries. Since the interval is constant, there is no backoff.
The interval is increased: with timeo=10 (1 sec) the retries will be
happening and t+1, t+3, t+6 etc - see my original mail on Jul 7:
http://www.spinics.net/lists/linux-nfs/msg22425.html
If that's not a backoff then what is?
max
On Fri, 5 Aug 2011 16:33:41 -0400, Chuck Lever wrote:
> I thought that to_maxval was 60 seconds (600 deciseconds). Once
> the effective timeo has increased to 60 seconds, it doesn't
> increase further. Thus, if the default timeo setting is already 60
> seconds, you get effectively a fixed 60 second timeout, right?
In trond's tree - include/linux/nfs_fs.h
#define NFS_MAX_TCP_TIMEOUT (600*HZ)
max
Max Matveev wrote:
The interval is increased: with timeo=10 (1 sec) the retries will be
happening and t+1, t+3, t+6 etc - see my original mail on Jul 7:
http://www.spinics.net/lists/linux-nfs/msg22425.html
If that's not a backoff then what is?
You're right. Sorry I misunderstood. Re-reading what you wrote I'm not
sure it could be made any clearer. Maybe change "timeout is increased" to
"timeout interval is increased." But I'd be happy with it as-is.
Max Matveev wrote:
NFS/TCP does linear backoff then retransmiting - the manpage
was mistakenly asserting the "no backoff" theory.
Actually, now that I made you change the wording, I think the original
wording was correct. "Backoff" refers to an increase in the interval
between retries. Since the interval is constant, there is no backoff.
I could be wrong. I think the term "backoff" was first used this way in
ALOHA. I've got some papers around here somewhere and can check.
But maybe the best thing would be to remove any reference to backoff, and
talk about retry instead.
Jim Rees wrote:
Max Matveev wrote:
NFS/TCP does linear backoff then retransmiting - the manpage
was mistakenly asserting the "no backoff" theory.
Actually, now that I made you change the wording, I think the original
wording was correct. "Backoff" refers to an increase in the interval
between retries. Since the interval is constant, there is no backoff.
Check this:
http://www.cs.utexas.edu/users/lam/NRL/backoff.html
So NFS over TCP uses a fixed retry interval, not a linear one. I don't
think it's correct to say "no backoff" but it's also not correct to say it's
"linear backoff," which implies the retry interval is linear in the number
of retries (you could argue that it's linear and the slope is zero but I
think that's misleading). The correct term might be "fixed backoff" or
"fixed retry interval."
On Aug 5, 2011, at 8:40 AM, Jim Rees wrote:
> Max Matveev wrote:
>
> NFS/TCP does linear backoff then retransmiting - the manpage
> was mistakenly asserting the "no backoff" theory.
>
> Actually, now that I made you change the wording, I think the original
> wording was correct. "Backoff" refers to an increase in the interval
> between retries. Since the interval is constant, there is no backoff.
>
> I could be wrong. I think the term "backoff" was first used this way in
> ALOHA. I've got some papers around here somewhere and can check.
>
> But maybe the best thing would be to remove any reference to backoff, and
> talk about retry instead.
I thought that to_maxval was 60 seconds (600 deciseconds). Once the effective timeo has increased to 60 seconds, it doesn't increase further. Thus, if the default timeo setting is already 60 seconds, you get effectively a fixed 60 second timeout, right?
If you specify a shorter timeo, then it linearly backs off to the to_maxval setting, which is 600 deciseconds. But Trond has argued that shorter settings are worse than useless.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 08/04/2011 01:47 AM, Max Matveev wrote:
> NFS/TCP does linear backoff then retransmiting - the manpage
> was mistakenly asserting the "no backoff" theory.
>
> Signed-off-by: Max Matveev <[email protected]>
> Signed-off-by: Jim Rees <[email protected]>
Committed...
steved.
> ---
> utils/mount/nfs.man | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index be91a25..ff0ed60 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -113,12 +113,16 @@ option may mitigate some of the risks of using the
> option.
> .TP 1.5i
> .BI 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 perform any kind of timeout backoff
> -for NFS over TCP.
> +The time in deciseconds (tenths of a second) the NFS client waits for a
> +response before it retries an NFS request.
> +.IP
> +For NFS over TCP the default
> +.B timeo
> +value is 600 (60 seconds).
> +The NFS client performs linear backoff: After each retransmission the
> +timeout is increased by
> +.BR timeo
> +up to the maximum of 600 seconds.
> .IP
> However, for NFS over UDP, the client uses an adaptive
> algorithm to estimate an appropriate timeout value for frequently used
> -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html