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@xxxxxxxxxx/ 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. Thanks, NeilBrown
