Re: [git pull] new mount API

From: Andy Lutomirski <luto@amacapital.net>
To: David Howells <dhowells@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [git pull] new mount API
Date: Fri, 24 Aug 2018 07:49:04 -0700	[thread overview]
Message-ID: <015EF93F-1BC8-4000-ABBC-233F73D09384@amacapital.net> (raw)
In-Reply-To: <362.1535103931@warthog.procyon.org.uk>

> On Aug 24, 2018, at 2:45 AM, David Howells <dhowells@redhat.com> wrote:

> 
> 
> 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?
> 

I would argue that “exclusive” means “semantically equivalent to getting a fully independent instance.”  This means, at least, that all options need to be respected as specified (or fail if they can’t be) and future reconfigure/remount actions only affect *this* instance and not others.

NFS might already meet these requirements, although I’m not sure about the latter one.

But it might be that adding CREATE_EXCLUSIVE is not all that useful and it would be better to have an API like you sketched where you first explicitly instantiate the driver and then you create however many trees (a la fsmount()) you want, where each tree has its own set of per-tree options like “subvol” for btrfs.