Re: [git pull] new mount API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux