Re: [PATCH 1/2] mount: ECONNREFUSED is a permanent error

Steve Dickson
2009-10-09T15:21:00Z

On 10/09/2009 11:13 AM, Chuck Lever wrote:
> 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.
I think the text-based mounts have it right...

>
> 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).
The former, IMHO.. I also notice that the retry timer does not work since
the mount waits in the kernel well passed the timer expiring...
>
> Automounter might want different behavior in this case, but we should
> ask around before making a final decision, probably.
Ian... What do you think??

steved.