On Tue, 2012-06-05 at 10:26 +0400, Michael Tokarev wrote: > Hello. > > Automount nfs mount code can happily perform NFSv4 mounts > without a help from portmapper: NFSv4 port is - usually - > 2049, and it is enough to perform the mount. It used to, yes, but maybe recent changes have broken that, I'm about to look into that. > > But automount - correctly - tries to contact the portmapper > anyway (unless the port is specified explicitly), and in > case the portmapper service is not running on the remote > host, this takes a few seconds to time out. > > This is because it uses connection-less UDP socket, which > does not receive network errors. Until the most recent changes that was the case. mount.nfs(8) doesn't do the probing it used to do for recent kernels, it just calls mount(2), passes the text options to the kernel and lets the kernel do the rest. But the kernel RPC behaves (necessarily) differently to user space RPC which has (recently) lead to lengthy timeouts on mounts to servers that aren't responding. > > In order to eliminate this timeout, the socket used to contact > the remote portmapper needs to be connected - this way, the > OS will report ECONNREFUSED error instantly and the mount > operation will proceed without delays even if the remote > portmapper is not available. Right, but the recent changes have changed the order to TCP then UDP so I'm not sure this is still accurate now, although I may not have changed them all, I need to check that. But I thought ECONNREFUSED meant just that, in which case UDP should be tried following that, in case only the TCP port is blocked. > > This is rpc_portmap_getport() function. > > I tried to follow the code, but the logic there is so twisted > I've lost track of things quite quickly. Yes, it is a bit convoluted. This code was originally written for two reasons. First to take control over the timeouts to avoid lengthy waits and second to reduce socket usage by allowing callers to reuse socket file descriptors. > > The question is: is it possible to use connected UDP sockets > there in all cases, or is conn_info->client reused for > something else? If it is, I guess we may just get rid of > cached (UDP) client and create new client for each call. Don't think so. > > Or is this completely backwards? I mean, UDP is really > unreliable protocol, for it to actually work the app > should retry sending packet in case of timeout, and the > protocol is easy to spoof too... Backward in the sense that we probably should (and should already) be using TCP first. Another thing is that, since the change to mount.nfs(8), we now also need to change to probing on simple automounts (as well as multi-mounts) in order to maintain a reasonable interactive response. > > Alternatively, we may try to contact 2049 port first, > and if that one does not respond, try to contact the > portmapper. But I'm not sure if this is right thing > to do to start with. Don't know that yet either. > > Thanks, > > /mjt > -- > To unsubscribe from this list: send the line "unsubscribe autofs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
