> 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. -- Chuck Lever
