On 6/11/19 1:44 PM, Trond Myklebust wrote: > 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. > What about nfsmount.conf? That seems like a more reasonable place to define how mounts should work... steved.
