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'. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
