On Wed, 2019-06-12 at 12:47 +0000, Trond Myklebust wrote: > On Wed, 2019-06-12 at 08:34 -0400, Steve Dickson wrote: > > 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... > > > > That has the exact same problem. As long as it defines global > defaults, > then fine, but if it pulverises the configuration for each and every > server, and makes it harder to trace what what overrides are being > applied, and where they are being applied then it is not helpful. > > Another issue there is that neither nfs.conf nor nfsmount.conf are > being used by all implementations of the mount utility. As far as I > know they are not supported by busybox, for instance. > BTW: Just a reminder that neither nfs.conf nor nfsmount.conf are kernel APIs. They are just configuration files for other utilities and daemons that actually call kernel APIs. So talk about shifting the responsibility for defining connection topologies to those files is not helpful unless you also describe (and develop) the kernel interfaces to be used by whatever reads those files. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
