On Fri, Aug 24, 2018 at 11:45 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > >> I'm not against merging this patchset (have nits about resuing the >> MS_* constants for the new API that I've complained about, but that's >> really easy to fix before -final), > > Can you send me a patch that does what you want here? They're only used by > fsmount() for creating a vfsmount and not used for the superblock creation or > reconfiguration. > >> but it may make sense to differentiate the legacy behavior from a saner one >> from the very start. I.e. rename FSCONFIG_CMD_CREATE > > I would suggest leaving it as-is and add an FSCONFIG_CMD_CREATE_EXCLUSIVE. > >> to something implying it's actually *not* a create in exclusive sense that >> one would first imply (and yeah, we have creat() and O_CREAT, which don't >> imply exclusivity, yet they at least have clear semantics that current super >> block creation does definitely not). > > The problem is that "exclusivity" isn't necessarily an easy thing to define. > Take nfs4 and btrfs for example. They creating a backing superblock that the > actual node is derived from (though in different ways). How do you define > what "exclusive" means in their case? Exclusive creation of a filesystem instance is just that: we promise that no one else is using that filesystem instance, and we can set options as we like, guaranteed that no bother to any other uses. Now, with block filesystems that can only be done once, obviously, so if someone already created a btrfs instance using /dev/foobar then trying to create another instance will fail with EEXIST, EBUSY or whaterver. For NFS it's a different story, it *is* possible to create several instances of the filesystem even if connecting to the same server, except then they will not share caches, will not have local coherency, etc.. Regardless, I think a "filesystem instance" is a pretty clear concept, that we can base a future API on and it's not just an internal implementation detail that the current mount(2) API makes look like. It *is* in fact the only concept that makes FSCONFIG_CMD_RECONFIGURE have sane meaning (i.e. I want to change *that* instance, and am fully aware what affect that will have on mounts of that instance). Compare that to "mount -o remount path"; that one would imply we are changing something for a mount that is at "path", but if there are more than one users of that instance (which is based on magic algorithm inside the filesystem) than that might have unwanted side effects. It's what Eric's complaint is about, and it's I think the root of the issue at hand. Thanks, Miklos
