On Tue, 2012-10-23 at 16:17 -0200, Leonardo Chiquitto wrote: > Hello, > > I noticed that recent versions of AutoFS are creating more load on NFS > servers and on the network. Further investigation revealed that since > commit 15fcfcd29b4 (autofs-5.0.6 - reinstate singleton mount probe), > AutoFS started to probe the proximity of NFS servers even when there's > only one server hosting the volume. > > The call sequence is: > prune_host_list() -> get_vers_and_cost() -> get_nfs_info() (twice) That's right. This was done because of potential long mount waits for mounts to a server that isn't available. > > In some circumstances, each call to get_nfs_info() will send more than > 10 requests to the server. This gets out of control quickly if the user > triggers, lets say, 100 mounts simultaneously. > > Is it possible to revert this change and fix the timeout issue in other > way? If not, I think it will be necessary to implement a positive cache > for reachable servers to reduce the amount of probing. Not really, the mount is now done in the kernel and the kernel has somewhat difference requirements for its RPC. It can't just give up on an RPC request because, I believe, that would increase the possibility of corruption. However, I did think that this wouldn't be good for everyone so I also changed MOUNT_WAIT to behave as it was before. That seemed sensible because MOUNT_WAIT is meant to provide a way to limit the time that autofs waits for a mount to complete. It also seemed sensible to not perform the probe in that case, and we needed a way to allow the previous behavior to be used. Have the user set MOUNT_WAIT to a sensible value for the site and that should give what's needed. Ian -- 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
