Re: Re: [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf

["NeilBrown" <neilb@suse.de>]

On Fri, 16 Apr 2021, Steve Dickson wrote:
> Hey Chuck! 
> 
> On 4/14/21 7:26 PM, Chuck Lever III wrote:
> > Hi Steve-
> > 
> >> On Apr 14, 2021, at 2:10 PM, Steve Dickson <SteveD@redhat.com> wrote:
> >>
> >> This is a tweak of the patch set Alice Mitchell posted last July [1].
> > 
> > That approach was dropped last July because it is not container-aware.
> > It should be simple for someone to write a udev script that uses the
> > existing sysfs API that can update nfs4_client_id in a namespace. I
> > would prefer the sysfs/udev approach for setting nfs4_client_id,
> > since it is container-aware and makes this setting completely
> > automatic (zero touch).
> As I said in in my cover letter, I see this more as introduction of
> a mechanism more than a way to set the unique id. The mechanism being
> a way to set kernel module params from nfs.conf. The setting of
> the id is just a side effect... 

I wonder if this is the best approach for setting module parameters.

rpc.nfsd already sets grace-time and lease-time - which aren't
exactly module parameters, but are similar - using values from nfs.conf.
Similarly statd sets /proc/fs/nfs/nlm_tcport based on nfs.conf.

I don't think these things should appear in nfs.conf as "kernel
parameters", but as service parameters for the particular service.
How they are communicate to the kernel is an internal implementation
detail.  Maybe it will involve setting module parameters (at least on
older kernels).

For the "identity" setting, I think it would be best if this were
checked and updated by mount.nfs (similar to the way mount.nfs will
check if statd is running, and will start it if necessary).  So should
it go in nfsmount.conf instead of nfs.conf?? I'm not sure.

It isn't clear to me where the identity should come from.
In some circumstances it might make sense to take it from nfs.conf.
In that case we would want to support reading /etc/netnfs/NAME/nfs.conf
where NAME was determined in much the same way that "ip netns identify"
determines a name.  (Compare inum of /proc/self/ns/net with the inum of
each name in /run/netns/).
If we did that, we could then support "$netns" in the conf file, and
allow

 [nfs]
  identity = ${hostname}-${netns}

in /etc/nfs.conf, and it would Do The Right Thing for many cases.

We have a partner who wants to make use of 'nconnect' but is
particularly inconvenienced by the fact that once there is any mount
from a given server it is no longer possible to change the nconnect
setting.  I have suggested they explore setting up a separate
net-namespace for "their" mounts which can be independent from "other"
mounts on the same machine.  If we could make that work with a degree of
transparency - maybe even a "-o netfs=foobar" mount option - that would
be a big help.

Thanks,
NeilBrown