]> git.decadent.org.uk Git - nfs-utils.git/commit
mount.nfs: try the next address after mount fails with ETIMEDOUT
authorJeff Layton <jlayton@redhat.com>
Tue, 19 Jun 2012 14:57:55 +0000 (10:57 -0400)
committerSteve Dickson <steved@redhat.com>
Tue, 19 Jun 2012 14:57:55 +0000 (10:57 -0400)
commit78ee5f378f295e7bff24a7be41b9361f406d4f8b
treeca0b725a6f04a8126878bb187b1b4e77f0dcb025
parentd18b89cd7352783580f3d3dde26f8617e36459b9
mount.nfs: try the next address after mount fails with ETIMEDOUT

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>
utils/mount/stropts.c