On 4 Feb 2022, at 13:45, Chuck Lever III wrote:
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.
This isn't a mechanism to deal with containers, its a small helper
utility
that we'd like to use to solve an existing, non-container problem in a
way
that's future-proof for containers.
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.
I disagree. This tool is immediately useful when I have multiple NAT-ed
NFS
clients with the same hostnames and they end up with identical NFS
client
identifiers. That's the problem this little utility helps to solve, and
that's the real-world issue we've been asked to fix.
I don't think we have to solve all the problems at once, and I think
this is
headed in the right direction. I can commit to working on the namespace
part.. but there's a number of things that aren't clear to me there:
- is udev namespace-aware?
- can we get udev rules to trigger for a namespace (my simple tests
show
that my "root" system-udevd doesnt see the creation or entry of
processes
into a new network namespace) Maybe we need to run udevd in every
network namespace?
- can uniquifiers be network-namespace uniquified by just using
information
available within a udev rule, or do we really need this utility to
be
namespace aware?
There's a bunch of stuff to discuss and figure out (unless someone else
already has), maybe we can start a new thread?
Ben
