All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Steve Dickson <SteveD@redhat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: [PATCH 1/8] nfs.man: clarify effect of 'retry' option.
Date: Thu, 14 Jul 2016 12:26:43 +1000	[thread overview]
Message-ID: <20160714022643.5874.60079.stgit@noble> (raw)
In-Reply-To: <20160714021310.5874.22953.stgit@noble>

The total timeout for a "mount" attempt to a non-responsive server
will always be a multiple of the time a single mount attempt in the
kernel takes, which for TCP defaults to about 4 minutes.

The documentation for the "retry" option seems to suggest that this can be used
to set a maximum but it really sets a time after which to stop retrying.
The total can be as much as "retry" plus the time for a single attempt.

So clarify the documentation a bit, and also note that retrans
defaults are different for UDP and TCP:
   #define NFS_DEF_UDP_RETRANS	(3)
   #define NFS_DEF_TCP_RETRANS	(2)

Reported-by: Howard Guo<hguo@suse.com>
Signed-off-by: NeilBrown <neilb@suse.com>
---
 utils/mount/nfs.man |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index e541cdc95cb1..a0f790a5961b 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -158,8 +158,8 @@ up to a maximum timeout length of 60 seconds.
 The number of times the NFS client retries a request before
 it attempts further recovery action. If the
 .B retrans
-option is not specified, the NFS client tries each request
-three times.
+option is not specified, the NFS client tries each UDP request
+three times and each TCP request twice.
 .IP
 The NFS client generates a "server not responding" message
 after
@@ -391,6 +391,16 @@ is 2 minutes, and the default value for background mounts is 10000 minutes
 If a value of zero is specified, the
 .BR mount (8)
 command exits immediately after the first failure.
+.IP
+Note that this only affects how many retries are made and doesn't
+affect the delay caused by each retry.  For UDP each retry takes the
+time determined by the
+.BR timeo
+and
+.BR retrans
+options, which by default will be about 7 seconds.  For TCP the
+default is 3 minutes, but system TCP connection timeouts will
+sometimes limit the timeout of each retransmission to around 2 minutes.
 .TP 1.5i
 .BI sec= flavors
 A colon-separated list of one or more security flavors to use for accessing



  parent reply	other threads:[~2016-07-14  2:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14  2:26 [PATCH 0/8] Assorted mount-related nfs-utils patches NeilBrown
2016-07-14  2:26 ` [PATCH 5/8] mountd: Don't export unmounted exports to NFSv4 NeilBrown
2016-07-14  2:26 ` [PATCH 2/8] mountd: remove the --exports-file option NeilBrown
2016-07-18 16:19   ` J. Bruce Fields
2016-07-14  2:26 ` [PATCH 7/8] mount: don't treat temporary name resolution failure as permanent NeilBrown
2016-07-19 23:01   ` NeilBrown
2016-07-14  2:26 ` [PATCH 4/8] mountd: cause attempts to access unmounted exportpoints to return ESTALE NeilBrown
2016-07-14  2:26 ` NeilBrown [this message]
2016-07-14  2:26 ` [PATCH 8/8] mount: use a public address for IPv6 callback NeilBrown
2016-07-14  2:26 ` [PATCH 3/8] mountd: remove 'dev_missing' checks NeilBrown
2016-07-18 20:01   ` J. Bruce Fields
2016-07-19 22:50     ` NeilBrown
2016-07-21 17:24       ` J. Bruce Fields
2016-08-11  2:51         ` NeilBrown
2016-08-16 15:21           ` J. Bruce Fields
2016-08-18  1:32             ` NeilBrown
2016-08-18  2:57               ` Chuck Lever
2016-08-19  1:31                 ` NeilBrown
2016-08-18 13:57               ` J. Bruce Fields
2016-08-19  1:28                 ` NeilBrown
2016-08-19 17:27                   ` J. Bruce Fields
2016-07-14  2:26 ` [PATCH 6/8] mountd: don't add paths to non-mounted export points to pseudo-root NeilBrown
2016-07-18 20:32   ` J. Bruce Fields
2016-07-19  8:00     ` Chuck Lever
2016-07-19 22:59     ` NeilBrown
2016-07-21 17:33       ` J. Bruce Fields
2016-07-25  7:22         ` NeilBrown
2016-07-28 20:54           ` J. Bruce Fields

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=20160714022643.5874.60079.stgit@noble \
    --to=neilb@suse.com \
    --cc=SteveD@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.