Re: v4 clientid uniquifiers in containers/namespaces

[Trond Myklebust <trondmy@hammerspace.com>]

On Wed, 2022-02-09 at 07:56 +1100, NeilBrown wrote:
> On Tue, 08 Feb 2022, Benjamin Coddington wrote:
> > On 7 Feb 2022, at 20:59, NeilBrown wrote:
> > 
> > > On Sun, 06 Feb 2022, Benjamin Coddington wrote:
> > > > Hi all,
> > > > 
> > > > Is anyone using a udev(-like) implementation with
> > > > NETLINK_LISTEN_ALL_NSID?
> > > > It looks like that is at least necessary to allow the init
> > > > namespaced udev
> > > > to receive notifications on
> > > > /sys/fs/nfs/net/nfs_client/identifier, which
> > > > would be a pre-req to automatically uniquify in containers.
> > > 
> > > Could you walk me through the reasoning here - or point me to
> > > where it
> > > has been discussed.
> > 
> > https://lore.kernel.org/linux-nfs/20210414181040.7108-1-steved@redhat.com/
> 
> Thanks.  I did remember that discussion though it was helpful to
> refresh
> my memory, and to be sure there is nothing else.
> 
> > 
> > > It seems to me that mount.nfs is the place to set
> > > nfs_client/identifier.
> > > It can be told (via /etc/nfs.conf or /etc/nfsmount.conf) how to
> > > generate
> > > and where to store the identifier.  It can check the current
> > > value and
> > > update if needed.  As long as the identifier is set before the
> > > first
> > > mount, there is no rush.
> > > 
> > > Why does it need to be done in response to a uevent??
> > 
> > I think the assertion was that it was the only sensible way, and it
> > does
> > seem to be better than exposing yet another knob when all that's
> > needed is a
> > way to distinguish and persist NFS clients when network namespaces
> > can come
> > and go at any time, and there can be a lot of them.
> 
> "assertion" is an apt word.  There wasn't a whole lot of reasoned
> argument, mostly just assertions.
> 
> The best argument was that "nfs.conf is not namespace aware", which
> is
> only somewhat true.  Using "ip netnfs exec" will make
> non-namepsace-aware tools work correctly in namespaces providing
> their
> config files are in /etc/netns/NAME - they get bind-mounted over the
> files in /etc.
> And of course /etc/nfs.conf can be MADE namespace aware.
> 
> There is also a reasonable argument that auto-editiing /etc/nfs.conf
> risks collision with an admin, but that is why we have
> /etc/nfs.conf.d
> 
> For me, the weakest part of the Steve's case was that he presented it
> as
> "setting module parameters via nfs.conf" rather than "configuring
> client
> identity via nfs.conf".  A number of the early negative responses
> were
> focused on the distraction of a module parameter being involved.
> 
> The weakness for the alternative, of course, is the fact that using
> the
> udev mechanism requires running udevd in each network namespace,
> which
> is an unnecessary burden.
> 
> So I still STRONGLY think that the identity should be set by
> mount.nfs
> reading (and writing) some file in /etc or /etc/netnfs/NAME, and I
> weakly think that the file should be in /etc/nfs.conf.d/ so that the
> reading is automagic.
> 

No. It's not a per-mount setting, so it has no business being in the
mount protocol.

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