Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     NeilBrown <neilb@suse.de>
Cc:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: v4 clientid uniquifiers in containers/namespaces
Date:   Tue, 08 Feb 2022 06:52:28 -0500
Message-ID: <A677D8A9-FD0B-43E5-82D6-E660CCB8B185@redhat.com>
In-Reply-To: <164428557862.27779.17375354328525752842@noble.neil.brown.name>
References: <6CEC5101-0512-4082-81F8-BDFEC5B6DF3A@redhat.com>
 <164428557862.27779.17375354328525752842@noble.neil.brown.name>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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/

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

Ben