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@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. > 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@xxxxxxxxxxxxxxx
