On Tue, 2019-06-11 at 11:35 -0400, Chuck Lever wrote: > > On Jun 11, 2019, at 11:20 AM, Trond Myklebust < > > trondmy@xxxxxxxxxxxxxxx> wrote: > > > > On Tue, 2019-06-11 at 10:51 -0400, Chuck Lever wrote: > > > > > If maxconn is a hint, when does the client open additional > > > connections? > > > > As I've already stated, that functionality is not yet available. > > When > > it is, it will be under the control of a userspace daemon that can > > decide on a policy in accordance with a set of user specified > > requirements. > > Then why do we need a mount option at all? > For one thing, it allows people to play with this until we have a fully automated solution. The fact that people are actually pulling down these patches, forward porting them and trying them out would indicate that there is interest in doing so. Secondly, if your policy is 'I just want n connections' because that fits your workload requirements (e.g. because said workload is both latency sensitive and bursty), then a daemon solution would be unnecessary, and may be error prone. A mount option is helpful in this case, because you can perform the setup through the normal fstab or autofs config file configuration route. It also make sense if you have a nfsroot setup. Finally, even if you do want to have a daemon manage your transport, configuration, you do want a mechanism to help it reach an equilibrium state quickly. Connections take time to bring up and tear down because performance measurements take time to build up sufficient statistical precision. Furthermore, doing so comes with a number of hidden costs, e.g.: chewing up privileged port numbers by putting them in a TIME_WAIT state. If you know that a given server is always subject to heavy traffic, then initialising the number of connections appropriately has value. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
