> On Feb 28, 2022, at 3:42 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Mon, 2022-02-28 at 20:15 +0000, Chuck Lever III wrote: >> >> >>> On Feb 28, 2022, at 3:06 PM, Trond Myklebust >>> <trondmy@xxxxxxxxxxxxxxx> wrote: >>> >>> On Mon, 2022-02-28 at 19:04 +0000, Chuck Lever III wrote: >>>> >>>> >>>>> On Feb 28, 2022, at 12:24 PM, Trond Myklebust >>>>> <trondmy@xxxxxxxxxxxxxxx> wrote: >>>>> >>>>>> Attempts to work toward solutions in this area seem to be >>>>>> ignored, >>>>>> the >>>>>> questions still stand. Until we can sort out and agree on a >>>>>> direction, >>>>>> self-NACK to this patch. >>>>> >>>>> A new mount option doesn't solve any problems that we can't >>>>> solve >>>>> with >>>>> the existing framework. >>>> >>>> I don't think a mount option was proposed. Rather, the mechanics >>>> of the udev rule would be done by mount.nfs without any changes >>>> to the administrative interface. >>>> >>> >>> That's not how I read this proposal: >>> >>>> Do you still want us to keep this approach, or will you accept a >>> mount >>>> option as: >>>> - first mount in a namespace sets the identifier >>>> - subsequent mounts with conflicting identifiers return an error >>> >>> >>> Which is why I responded as I did. >> >> Ah! Well, I read "mount option" as "mount alternative", I guess >> I was filling in some context from previous dialog on the topic. >> >> I agree with you that an actual mount option -- that is, a new >> administrative interface -- is not desirable or necessary. >> >> But I assert that having mount.nfs take care of initializing the >> uniquifier for the net namespace is convenient, and can be done >> automatically and reliably. >> > > Again, if we do this, then I'd want the actual tool that initialises > the uniquifier to be a separate one that gets called by mount if > necessary. > Otherwise we'll have to consider duplicating that code in busybox and > all the other tools that have private implementations of 'mount'. I don't have a problem with mount.nfs invoking a separate tool or doing it as part of a systemd target that precedes remote-fs. The tricky thing here seems to be guaranteeing that the uniquifier is set before the first mount can be done. -- Chuck Lever
