On 18 Apr 2022, at 11:58, Chuck Lever wrote: > To enable NFSv4 to work correctly, NFSv4 client identifiers have > to be globally unique and persistent over client reboots. We > believe that in many cases, a good default identifier can be > chosen and set when a client system is imaged. > > Because there are many different ways a system can be imaged, > provide an explanation of how NFSv4 client identifiers and > principals can be set by install scripts and imaging tools. > > Additional cases, such as NFSv4 clients running in containers, also > need unique and persistent identifiers. The Linux NFS community > sets forth this explanation to aid those who create and manage > container environments. > > Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > --- > .../filesystems/nfs/client-identifier.rst | 216 ++++++++++++++++++++ > Documentation/filesystems/nfs/index.rst | 2 > 2 files changed, 218 insertions(+) > create mode 100644 Documentation/filesystems/nfs/client-identifier.rst > 8< --- > +Linux provides two mechanisms to add uniqueness to its "co_ownerid" > +string: > + > + nfs.nfs4_unique_id > + This module parameter can set an arbitrary uniquifier string > + via the kernel command line, or when the "nfs" module is > + loaded. > + > + /sys/fs/nfs/client/net/identifier > + This virtual file, available since Linux 5.3, is local to the > + network namespace in which it is accessed and so can provide > + distinction between network namespaces (containers) when the > + hostname remains uniform. Docs are currently wrong because the path is actually: /sys/fs/nfs/net/nfs_client/identifier as originally created on bf11fbdb20b38. It would be trivial to change the docs, but I have to say I think the "nfs_client" path component is redundant. The docs version with "client" also seems redundant, since /sys/fs/nfs should only every contain client things. Is it too late to move things a bit? Ben
