mount retries

mount retries

[Tom Haynes]

Does the Linux mount client have any algorithms to retry a NFS mount?

Or does it depend entirely on the underlying protocol.

I.e., would TCP retry and UDP just give up?

Re: mount retries

[Chuck Lever]

On Oct 2, 2009, at 5:45 PM, Tom Haynes wrote:
> Does the Linux mount client have any algorithms to retry a NFS mount?
>
> Or does it depend entirely on the underlying protocol.
>
> I.e., would TCP retry and UDP just give up?

The behavior is pretty complex.

There's a large retry loop that can try mounts in the foreground, or  
automatically daemonize if the mount request isn't successful at  
first.  The retry loop continues as long as there are server or  
network problems that prevent a definitive answer from the server from  
getting back to the client.  There is a retry= mount option to cut off  
retrying after a certain amount of time.

If a particular NFS version or transport is requested by the user, it  
will attempt to use those settings, and fail if those aren't available  
on the server.  For v2/v3, any parameters not specified by the user,  
like port, transport, or version, are filled in with pmap queries.   
The choice of transport is a little odd; if the user didn't specify a  
transport, it looks like the transport that worked for the pmap query  
is chosen regardless of what is registered.  ie, if a TCP pmap query  
fails, but the UDP pmap query worked, we go with UDP, whether or not  
the NFS service is registered on UDP.

For v4, it skips the pmap query and just dives into the kernel to try  
connecting with the server.

If none of these work, and the mount command hasn't gotten a definite  
yes or no from the server (and all of the mount options are valid and  
legal) it will keep trying until it works, the user hits ^C, or the  
retry timer expires.  The ^C part doesn't apply to daemonized mounts.

The exact retry behavior depends on whether user space or the kernel  
is trying to do the talking.  NFSv4 and text-based NFSv2/v3 mounts do  
most of the talking from the kernel.  Text-based mounts do a user  
space pmap query or two, but the MNT request comes from the kernel.   
Also, UDP retries a few times, but usually gives up after 30 seconds  
or so, but TCP can retry the transport connect for over 3 minutes,  
even before it gets to send any requests at all.

I'm pretty sure I didn't answer your question.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: mount retries

[Tom Haynes]

Chuck Lever wrote:
>
> The exact retry behavior depends on whether user space or the kernel 
> is trying to do the talking.  NFSv4 and text-based NFSv2/v3 mounts do 
> most of the talking from the kernel.  Text-based mounts do a user 
> space pmap query or two, but the MNT request comes from the kernel.  
> Also, UDP retries a few times, but usually gives up after 30 seconds 
> or so, but TCP can retry the transport connect for over 3 minutes, 
> even before it gets to send any requests at all.
>
> I'm pretty sure I didn't answer your question.

Thanks Chuck, you actually nailed what I didn't ask properly.

The UDP retries being at 30s correlates with what I was seeing.