diff mbox

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

Message ID 20110805021903.C84608198734@regina.usersys.redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Max Matveev Aug. 4, 2011, 5:47 a.m. UTC 
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(-)

Comments

Jim Rees Aug. 5, 2011, 12:40 p.m. UTC | #1 
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.
--
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
Jim Rees Aug. 5, 2011, 1:34 p.m. UTC | #2 
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."
--
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
Chuck Lever Aug. 5, 2011, 8:33 p.m. UTC | #3 
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



--
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
Max Matveev Aug. 6, 2011, 1:40 a.m. UTC | #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
--
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
Jim Rees Aug. 6, 2011, 12:43 p.m. UTC | #5 
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.
--
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
Max Matveev Aug. 8, 2011, 12:50 a.m. UTC | #6 
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


--
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
diff mbox

Patch

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