On Oct 9, 2009, at 9:16 AM, Steve Dickson wrote:
On 10/08/2009 01:37 PM, Chuck Lever wrote:
I had assumed early on that mount.nfs should retry a refused
connection.
Apparently this is not the case. Legacy mount.nfs4 fails immediately
if the NFS server refuses the connection. Legacy mount.nfs and
text-based mount.nfs both fail immediately if the rpcbind service is
refusing connections.
What about if the server is on the way up (i.e the network is up)
but has not started the NFS service? In that window, the server will
return ECONNREFUSED since nobody is listening, but in a very short
time
there will be a listener... The mount should not fail in that case...
I agree, but I think it does fail today, and it has behaved this way
for a long while. No one has complained about it. I'm actually not
arguing in favor of either behavior; just reporting that the current
behavior is inconsistent.
With the current code, legacy and text-based v2/v3 fails immediately
if the server's rpcbind refuses connection... Legacy mount.nfs4 fails
immediately if the NFS server refuses connection. Text-based
mount.nfs4 retries in this case.
So we will either need to fix v2/v3 to continue retrying, or fix NFSv4
to stop retrying. The retries would stop after mount.nfs's retry
timer expires (just like the case where the server isn't responding at
all).
Automounter might want different behavior in this case, but we should
ask around before making a final decision, probably.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
