> 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. 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. Who volunteers to implement this mechanism in mount.nfs ? > 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. > 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
