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

[Trond Myklebust <trondmy@hammerspace.com>]

On Thu, 2021-04-15 at 23:30 +0000, Trond Myklebust wrote:
> On Thu, 2021-04-15 at 16:37 +0000, Chuck Lever III wrote:
> > 
> > 
> > > On Apr 15, 2021, at 11:33 AM, Steve Dickson <SteveD@RedHat.com>
> > > 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.
> > 
> > Yep, I got that.
> > 
> > I'm not addressing the question of whether adding a
> > mechanism to set a module parameter in nfs.conf is good
> > or not. I'm saying nfs4_client_id is not an appropriate
> > parameter to add to nfs.conf. Can you pick another
> > module parameter as an example for your mechanism?
> > 
> > 
> > > The mechanism being
> > > a way to set kernel module params from nfs.conf. The setting of
> > > the id is just a side effect... 
> > > 
> > > Why spread out the NFS configuration?  Why not
> > > just keep it in one place... aka nfs.conf?
> > 
> > We need to understand whether a module parameter is not
> > going to work in nfs.conf because that setting needs to
> > be namespace-aware. In this case, this setting does indeed
> > need to be namespace-aware. nfs.conf is not aware of
> > network namespaces.
> > 
> > 
> > > Plus we could document all the kernel params in nfs.conf
> > > and the nfs.conf man page. The only documentation I know 
> > > of is in the kernel tree.
> > 
> > OK, but that's not relevant to whether nfs.conf is the
> > right place to set nfs4_client_id.
> > 
> > 
> > > As far as not being container-aware... that might true
> > > but it does not mean its not useful to set the id from
> > > nfs.conf...
> > 
> > Yes, it does mean that in that case. It's completely
> > broken to use the same nfs4_client_id in every network
> > namespace.
> > 
> > 
> > > Actual I have customers asking for this type
> > > of functionality
> > 
> > Ask yourself why they might want it. It's probably because
> > we don't set it correctly currently. If we have a way to
> > automatically get it right every time, there's really no
> > need for this setting to be exposed.
> > 
> > I do agree that it's long past time we should be setting
> > nfs4_client_id properly. I would rather see a udev script
> > developed (you, me, or Alice could do it in an afternoon)
> > first. If that doesn't meet the actual customer need, then
> > we can revisit.
> > 
> 
> Right. The only sensible solution in a containerised world is a udev
> script that sets /sys/fs/nfs/net/nfs_client/identifier when triggered.
> 
> Note that we really want something that generates a random uuid, and
> then persists it so that it can be retrieved on reboot or restart of
> the container. Something similar to systemd-machine-id-setup, but that
> can be called from udev.
> 

Here is a skeleton example:

[root@leira rules.d]# cat /etc/udev/rules.d/50-nfs4.rules 
ACTION=="add" KERNEL=="nfs_client" ATTR{identifier}=="(null)" PROGRAM="/usr/sbin/nfs4_uuid" ATTR{identifier}="%c"

[root@leira rules.d]# cat /usr/sbin/nfs4_uuid 
#!/bin/bash
#
if [ ! -f /etc/nfs4_uuid ]
then
	uuid="$(uuidgen -r)"
	echo -n ${uuid} > /etc/nfs4_uuid
else
	uuid="$(cat /etc/nfs4_uuid)"
fi
echo ${uuid}


Obviously, the /usr/sbin/nfs4_uuid would need to be fleshed out a
little more to ensure that the file /etc/nfs4_uuid actually contains a
uuid in the right format, but you get the gist...

With the above additions, I end up with a repeatable

[root@leira rules.d]# modprobe nfs4
[root@leira rules.d]# cat /sys/fs/nfs/net/nfs_client/identifier 
7f9f211b-0253-4ef8-a970-b1b0f600af02
[root@leira rules.d]# cat /etc/nfs4_uuid 
7f9f211b-0253-4ef8-a970-b1b0f600af02

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com