> On Feb 4, 2022, at 10:49 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> 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
