On Thu, 31 May 2012 10:28:49 -0400 Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On May 31, 2012, at 9: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. > > Bzzzzt. AF fallback is only legal to do if the admin did not specify a netid. > > Can you demonstrate that your patch works correctly if an IPv6 netid is specified? "Correctly" here means that no fallback occurs. > If someone specifies an IPv6 netid (via proto= option) then we would set AF_INET6 in the addrinfo "hints" and there will be no IPv4 addresses in the mi->address list. So, this does still work correctly when someone specifies an ipv6 netid. Chuck also pointed out on IRC that the description was a little unclear, since it was specific to my test rig where the server had a single IPv6 and IPv4 address in DNS. The loop that retries against different addresses doesn't care about whether the addrs are v4 or v6. What this really tells mount.nfs to do is to keep trying different addresses in the list if there are any instead of giving up on an ETIMEDOUT error. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
