> On Mar 14, 2022, at 8:41 PM, NeilBrown <neilb@xxxxxxx> wrote:
>
> On Tue, 15 Mar 2022, Chuck Lever III wrote:
>> Hi Neil-
>>
>>> +.IP \- 2
>>> +NFS-root (diskless) clients, where the DCHP server (or equivalent) does
>>> +not provide a unique host name.
>>
>> Suggest this addition:
>>
>> .IP \- 2
>>
>> Dynamically-assigned hostnames, where the hostname can be changed after
>> a client reboot, while the client is booted, or if a client often
>> repeatedly connects to multiple networks (for example if it is moved
>> from home to an office every day).
>
> This is a different kettle of fish. The hostname is *always* included
> in the identifier. If it isn't stable, then the identifier isn't
> stable.
>
> I saw in the history that when you introduced the module parameter it
> replaced the hostname. This caused problems in containers (which had
> different host names) so Trond changed it so the module parameter
> supplemented the hostname.
>
> If hostnames are really so poorly behaved I can see there might be a
> case to suppress the hostname, but we don't have that option is current
> kernels. Should we add it?
I didn't fully understand this comment before. I assume you are
referring to:
55b592933b7d ("NFSv4: Fix nfs4_init_uniform_client_string for net namespaces")
That will likely break reboot recovery if the container's nodename
changes over a reboot.
My (probably limited) understanding is that using the udev rule to
always add a uniquifier could have helped make it possible to remove
the hostname from the co_ownerid.
For the record, I take back this statement:
> I don't think we need to
> exclude the hostname from the nfs_client_id4 -- in fact some folks
> might prefer keeping the hostname in there as an eye-catcher. But
> it's simply that the hostname by itself does not provide enough
> uniqueness.
Since the nodename can change at inopportune times (like over a
reboot), including it in the co_ownerid string can sometimes be
problematic. But I don't have a better suggestion at this time.
> This conversation seems to be going around in circles and not getting
> anywhere. As as I have no direct interest (the SUSE bugzilla has
> precisely 1 bug relating to NFS and non-unique hostnames, and the
> customer seemed to accept the requirement of unique hostnames) I am
> going to bow out. I might post one more attempt at a documentation
> update ... or I might not.
I now agree that the Linux NFS community will need to work with
packagers and distributors, and that we will not arrive at a one-
size-fits-all tool by ourselves.
I'll try to pick up the documentation torch. Thanks for your
efforts so far.
--
Chuck Lever
