On 3/4/22 11:15 AM, Chuck Lever III wrote:
On Mar 4, 2022, at 10:54 AM, Steve Dickson <steved@xxxxxxxxxx> wrote:
Hey!
On 3/3/22 8:13 PM, NeilBrown wrote:
On Fri, 04 Mar 2022, Trond Myklebust wrote:
On Thu, 2022-03-03 at 14:26 +1100, NeilBrown wrote:
On Wed, 02 Mar 2022, Chuck Lever III wrote:
The remaining part of this text probably should be
part of the man page for Ben's tool, or whatever is
coming next.
My position is that there is no need for any tool. The total amount
of
code needed is a couple of lines as presented in the text below. Why
provide a wrapper just for that?
We *cannot* automatically decide how to find a name or where to store
a
generated uuid, so there is no added value that a tool could provide.
We cannot unilaterally fix container systems. We can only tell
people
who build these systems of the requirements for NFS.
I disagree with this position. The value of having a standard tool is
that it also creates a standard for how and where the uniquifier is
generated and persisted.
Otherwise you have to deal with the fact that you may have a systemd
script that persists something in one file, a Dockerfile recipe that
generates something at container build time, and then a home-made
script that looks for something in a different location. If you're
trying to debug why your containers are all generating the same
uniquifier, then that can be a problem.
I don't see how a tool can provide any consistency.
It seems to me that having a tool with its own man page directed
towards Linux distributors would be the central place for this
kind of configuration and implementation. Otherwise, we will have
to ensure this is done correctly for each implementation of
mount.
Is there some standard that say how containers should be built, and
where tools can store persistent data? If not, the tool needs to be
configured, and that is not importantly different from bash being
configured with a 1-line script to write out the identifier.
IMO six of one, half dozen of another. I don't see this being
any more or less safe than changing each implementation of mount
to deal with an NFS-specific setting.
I'm not strongly against a tools, I just can't see the benefit.
I think I agree with this... Thinking about it... having a command that
tries to manipulate different containers in different ways just
seems like a recipe for disaster... I just don't see how a command would
ever get it right... Hell we can't agree on its command's name
much less what it will do. :-)
To be clear what you are advocating, each implementation of mount.nfs,
including the ones that are not shipped with nfs-utils (like Busybox
and initramfs) will need to provide a mechanism for setting the client
uniquifier. Just to confirm that is what is behind door number one.
Well I can't speak for mount.nfs that are not in nfs-utils.
I'm assuming they are going to do... what are going to do...
regardless of what we do. At least we will give them a
guideline of what needs to be done.
Since it is just a line or two of code, it might be of little
harm just to go with separate implementations for now and stop
talking about it. If it sucks, we can fix the suckage.
Right I see documenting what needs to happen is the
first step. Heck don't we even know how accurate that
documentation is... yet! Once we vet the doc to make
sure it is accurate... Maybe then we could come up
with a auto-configuration solution that has been
proposed.
Who volunteers to implement this mechanism in mount.nfs ?Well, there has been 3 implementations shot down
which tells me, as a community, we need to get
more of an idea of what needs to happen and how.
That's why I think Neil's man page additions
is a good start.
So I like idea of documenting when needs to happen in the
different types of containers... So I think the man page
is the way to go... and I think it is the safest way to go.
Chuck, if you would like tweak the verbiage... by all means.
I stand ready.
That I have confidence in. :-) Thank you!
steved.
Neil, will be a V2 for man page patch from this discussion
or should I just take the one you posted? If you do post
a V2, please start a new thread.
steved.
--
Chuck Lever
