On Tue, 2019-06-11 at 13:32 -0400, Chuck Lever wrote: > > On Jun 11, 2019, at 12:41 PM, Trond Myklebust < > > trondmy@xxxxxxxxxxxxxxx> wrote: > > > > 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. > > Agreed that it demonstrates that folks are interested in having > multiple connections. I count myself among them. > > > > 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. > > Why wouldn't that be the default out-of-the-shrinkwrap configuration > that is installed by nfs-utils? What is the point of forcing people to run a daemon if all they want to do is set up a fixed number of connections? > > > 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. > > NFSROOT is the only usage scenario where I see a mount option being > a superior administrative interface. However I don't feel that > NFSROOT is going to host workloads that would need multiple > connections. KIS > > > > 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. > > Again, I don't see how this is not something a config file can do. You can, but that means you have to keep said config file up to date with the contents of /etc/fstab etc. Pulverising configuration into little bits and pieces that are scattered around in different files is not a user friendly interface either. > The stated intent of "nconnect" way back when was for > experimentation. > It works great for that! > > I don't see it as a desirable long-term administrative interface, > though. I'd rather not nail in a new mount option that we actually > plan to obsolete in favor of an automated mechanism. I'd rather see > us design the administrative interface with automation from the > start. That will have a lower long-term maintenance cost. > > Again, I'm not objecting to support for multiple connections. It's > just that adding a mount option doesn't feel like a friendly or > finished interface for actual users. A config file (or re-using > nfs.conf) seems to me like a better approach. nfs.conf is great for defining global defaults. It can do server specific configuration, but is not a popular solution for that. Most people are still putting that information in /etc/fstab so that it appears in one spot. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
