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>
Signed-off-by: Steve Dickson <steved@redhat.com>
case ECONNREFUSED:
case EOPNOTSUPP:
case EHOSTUNREACH:
+ case ETIMEDOUT:
continue;
default:
goto out;
switch (errno) {
case ECONNREFUSED:
case EHOSTUNREACH:
+ case ETIMEDOUT:
continue;
default:
goto out;