Re: [git pull] new mount API

From: Miklos Szeredi <miklos@szeredi.hu>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Al Viro <viro@zeniv.linux.org.uk>,
	David Howells <dhowells@redhat.com>,
	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 11:29:22 +0200	[thread overview]
Message-ID: <CAJfpegtvGv5tUtb6ZCfh+tQjns=_haz4V873QLZzrL0bxxJg7g@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegtJjy74cjcDjVCF9uMFYy028U9whsNroxDwe4pc9BVXdg@mail.gmail.com>

On Fri, Aug 24, 2018 at 10:56 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Fri, Aug 24, 2018 at 10:38 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Fri, Aug 24, 2018 at 8:05 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>>> On Thu, Aug 23, 2018 at 09:51:00PM -0700, Andy Lutomirski wrote:
>>>> When this was reviewed earlier, a problem was identified.  I asked if
>>>> it had been addressed.  I did *not* say that it was mandatory to
>>>> address it, nor did I say anything about reworking fs drivers.
>>>>
>>>> A reasonable answer might have been "avoiding this pitfall in the new
>>>> API would involve a large amount of reworking of existing filesystem
>>>> drivers.  I think that the new API, as is, has enough benefits that it
>>>> makes sense to merge it even with this pitfall, and, if needed, we can
>>>> introduce an improved version down the road."
>>>
>>> It's also not clear that an API that you think is "cleaner" would
>>> actually be more usable.  In fact, I believe it's going to be a sh*t
>>> show for userspace, because it won't be obvious what will work, and
>>> what will cause an error of the form, "sorry we can't do this cleaner
>>> thing that some people think is better".  Which means a huge amount of
>>> special casing in the program, or a lot of very surprising failures
>>> that will then get exposed to the system administrator, many of whom
>>> haven't really had much of a problem with the existing mount(8) user
>>> interface.
>>
>> In what way is the kernel better suited to read the mind of the poor
>> sysadmin, than a userspace helper program?
>
> I have a concrete example:  mount -oloop.  You can leave it to
> mount(8) to automagically find an existing loop device or setup a new
> one, or you can do the low level thing and set up your own loop device
> and mount it.  Same story as NFS and friends, except it's not the
> kernel that does the magic "same source -> same sb" policy but the
> mount(8) utility.  Ever notice the difference?  See?   And yeah, there
> are races involved, and userspace is perfectly suited to deal with
> them.

And to continue from that thought, a namespace for filesystem
instances could, for example, live under /dev/fs/$FSTYPE/$INSTANCE

Naming the $INSTANCE could be done by the one creating that instance,
or in case of legacy mounts could have a fixed prefix + sequence
number, or something similar.

All this could come later, let's just not exclude the possibility of
using the new API in this way.

Thanks,
Miklos