Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers

[Chuck Lever III <chuck.lever@oracle.com>]

> On Feb 4, 2022, at 10:49 AM, Benjamin Coddington <bcodding@redhat.com> wrote:
> 
> On 4 Feb 2022, at 10:17, Chuck Lever III wrote:
> 
>> As discussed in earlier threads, we believe that storing multiple unique-ids
>> in one file, especially without locking to prevent tearing of data in the
>> file, is problematic. Now, it might be that the objection to this was based
>> on storing these in a file that can simultaneously be edited by humans
>> (ie, /etc/nfs.conf). But I would prefer to see a separate file used for
>> each uniquifier / network namespace.
> 
> This tool isn't trying to store uniquifiers for multiple namespaces, or
> describe how it ought to be used in relation to namespaces.  It only
> attempts to create a fairly persistent unique value that can be generated
> and consumed from a udev rule.
> 
> I think the problem of how to create uniquifiers for every net namespace
> might easily be solved by bind-mounding /etc/nfs4-id into the
> namespace-specific filesystem, or a number of other ways.  That would be an
> interesting new topic.

I don't think that's a new topic at all. This mechanism needs to
deal with containers properly from day one. That's why we are
using a udev rule for this purpose in the first place instead of
something more obvious.

The problem is that a network namespace (to which the persistent
uniquifier is attached) and an FS namespace (in which the persistent
uniquifier is stored) are created and managed independently.

We need to agree on how NFSv4 clients in containers are to be
supported before the proposed tool can be evaluated fully.


--
Chuck Lever