[PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Max Matveev]

NFS/TCP does linear backoff then retransmiting - the manpage
was mistakenly asserting the "no backoff" theory.

Signed-off-by: Max Matveev <makc@redhat.com>
Signed-off-by: Jim Rees <rees@umich.edu>
---
 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

Re: [PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Jim Rees]

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.

Re: [PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Jim Rees]

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."

Re: [PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Chuck Lever]

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

Re: [PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Max Matveev]

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

Re: [PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Max Matveev]

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

Re: [PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Jim Rees]

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.

Re: [PATCH v2] Update nfs(5) manpage - timeo for NFS/TCP

[Steve Dickson]

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 <makc@redhat.com>
> Signed-off-by: Jim Rees <rees@umich.edu>
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html