On Thu, 17 Feb 2022, Benjamin Coddington wrote:
> How can we figure out what we want to do as a community before doing
> it all the ways?
The evidence suggests that we can't. Maybe we shouldn't.
Or maybe we can take a completely different approach. As I like to say:
"When in doubt, document." (OK, I just made that up...)
I propose the following text to be added to nfs(5) or maybe put in a
separate man page - nfs-container(5).
NFS IN A CONTAINER
When NFS is used to mount filesystems in a container, and specifically
in a separate network namespace, these mounts are treated as quite
separate from any mounts in a different container or not in a
container (i.e. in a different network namespace).
In the NFSv4.x protocol, each client must have a unique identifier.
This is used by the server to determine when a client has restarted,
so any state from a previous instance can be discarded. So any two
concurrent clients that might access the same server MUST have
different identifiers, and any two consecutive instances of the same
client SHOULD have the same identifier.
Linux constructs the identifier (referred to as co_ownerid in the NFS
specifications) from various pieces of information, three of which can
be controlled by the sysadmin:
- the hostname. This can be different in different containers if they
have different "UTS" namespaces. If the container system ensures
each container sees a unique host name, then this is
sufficient for a correctly functioning NFS identifier.
The host name is copied when the first NFS filesystem is mounted in
a given network namespace. Any subsequent change in the apparent
hostname will not change the NFSv4 identifier.
- the value of the nfs.nfs4_unique_id module parameter. This is the
same for all containers on a given host so is not useful to
differentiate between containers.
- the value stored in /sys/fs/nfs/client/net/identifier. This virtual
file is local to the network namespace that it is accessed in and so
can provided uniqueness between containers when the hostname is
uniform among containers.
This value is empty on namespace creation. though there is a pending
kernel patch which initialises it to a random value. This would mean
that containers which currently rely simply on a unique hostname to
create unique NFS identifiers, will now *not* have a stable
identifier from one instance to the next. This may be a regression,
so the patch should probably be reconsidered.
If the value is to be set, that should be done before the first
mount (much as the hostname is copied before the first mount).
If the container system has access to some sort of per-container
identity, then a command like
uuidgen --sha1 --namespace @url -N "nfs:$CONTAINER_ID" \
> /sys/fs/nfs/client/net/identifier
might be suitable. If the containre system provides no stable name,
but does have stable storage, then something like
[ -s /etc/nfsv4-uuid ] || uuidgen > /etc/nfsv4-uuid &&
cat /etc/nfsv4-uuid > /sys/fs/nfs/client/net/identifier
would suffice.
If a container has neither a stable name nor stable (local) storage,
then it is not possible to provide a stable identifer, so providing
a random one to ensure uniqueness would be best
uuidgen > /sys/fs/nfs/client/net/identifier
Comments, revisions, etc most welcome.
Thanks
NeilBrown
