From: Steve Dickson <SteveD@redhat.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-nfs@vger.kernel.org, chuck.lever@oracle.com
Subject: Re: [PATCH] mount.nfs: try the next address after mount fails with ETIMEDOUT
Date: Tue, 19 Jun 2012 10:58:06 -0400 [thread overview]
Message-ID: <4FE0937E.3010705@RedHat.com> (raw)
In-Reply-To: <1338469436-5411-1-git-send-email-jlayton@redhat.com>
On 05/31/2012 09:03 AM, Jeff Layton wrote:
> If a NFS mount attempt fails with an ETIMEDOUT error, the mount.nfs code
> doesn't currently attempt the next address in the list. For a NFSv4 mount
> the initial mount() call almost always ends up going over
> NFS_DEF_FG_TIMEOUT_MINUTES and the mount is never retried.
>
> For a v3 mount, it ends up continually retrying against the same IPv6
> address, and never tries the IPv4 address. Eventually it gives up once
> it hits the NFS_DEF_FG_TIMEOUT_MINUTES timeout.
>
> It's possible that a server is just unreachable via IPv6 (due to a
> routing misconfiguration for instance), or is dropping IPv6 frames on
> the floor. In that situation, it might still be reachable via IPv4 and
> trying the next address could have allowed the mount to succeed.
>
> Fix this by treating ETIMEDOUT in a similar fashion to ECONNREFUSED.
> Have the client try the next address in the list before giving up and
> returning an error.
>
> Our QA folks noticed this after a routing problem in one of our test
> labs. I was able to reproduce it by having the server drop incoming
> IPv6 frames from the client's address.
>
> With this patch, the mount eventually succeeds over IPv4 instead of
> returning an error.
>
> Cc: Chuck Lever <chuck.lever@oracle.com>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
Committed...
steved.
> ---
> utils/mount/stropts.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> index e09aa7c..0aa9a75 100644
> --- a/utils/mount/stropts.c
> +++ b/utils/mount/stropts.c
> @@ -665,6 +665,7 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
> case ECONNREFUSED:
> case EOPNOTSUPP:
> case EHOSTUNREACH:
> + case ETIMEDOUT:
> continue;
> default:
> goto out;
> @@ -752,6 +753,7 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
> switch (errno) {
> case ECONNREFUSED:
> case EHOSTUNREACH:
> + case ETIMEDOUT:
> continue;
> default:
> goto out;
prev parent reply other threads:[~2012-06-19 14:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-31 13:03 [PATCH] mount.nfs: try the next address after mount fails with ETIMEDOUT Jeff Layton
2012-05-31 14:28 ` Chuck Lever
2012-05-31 15:40 ` Jeff Layton
2012-05-31 20:19 ` Chuck Lever
2012-06-19 14:58 ` Steve Dickson [this message]
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=4FE0937E.3010705@RedHat.com \
--to=steved@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@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.