On Thu, Aug 23, 2018 at 05:16:53PM -0700, Andy Lutomirski wrote: > On Thu, Aug 23, 2018 at 5:08 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > > Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > > >> Has anything been done to ensure that the behavior when doing > >> FSCONFIG_CMD_CREATE against an already-mounted block device is > >> reasonable? > > > > For the moment, I've left it as the same behaviour as for mount(2) since > > mount(2) now uses the same mechanism internally and we aren't permitted to > > break userspace. > > > > I would like to add at least one flag to stipulate that, in the case of an > > incompatible collision, you can get a failure - but defining what is meant by > > incompatible isn't necessarily trivial, and would vary by filesystem *and* the > > LSM. > > > > However, I don't want to start reengineering everything this close to the > > merge window and we don't really need it immediately. > > > > The problem is that, once this ends up merged, then we're kind of > stuck with it, too. It would be a bit sad if your better proposal for > handling nfs and instantiation of filesystems in general were added in > the next release and then we end up with the current > FSCONFIG_CMD_CREATE as a permanently supported but non-preferred > option. For fuck sake, mount(2) is a permanently supported option! Folks, get over it - you are mixing entirely different issues. You know, I know and everyone even remotely sane knows that mount(2) *IS* *NOT* *GOING* *AWAY*. And it's not changing semantics either. So bemoaning the "permanently supported non-preferred options" is utter lunacy. It's there and it will remain there, period. We do not break userland. And "their local scripts would break terribly inside userns container" does *NOT* render those second-class in any sense. So you can curse the current behaviour of mount(2) and I even agree with some of that, but we are not going to be able to remove that. Yes, it would've been nice if, etc., but it's not going to happen. Not now, not for many years.
