From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f67.google.com ([209.85.218.67]:45114 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726246AbeHXNDL (ORCPT ); Fri, 24 Aug 2018 09:03:11 -0400 Received: by mail-oi0-f67.google.com with SMTP id t68-v6so3042677oie.12 for ; Fri, 24 Aug 2018 02:29:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180823223145.GK6515@ZenIV.linux.org.uk> <24340.1535069316@warthog.procyon.org.uk> <20180824003105.GL6515@ZenIV.linux.org.uk> <184842E4-9368-463D-9131-D9A5F686C319@amacapital.net> <20180824031311.GM6515@ZenIV.linux.org.uk> <20180824060532.GG16817@thunk.org> From: Miklos Szeredi Date: Fri, 24 Aug 2018 11:29:22 +0200 Message-ID: Subject: Re: [git pull] new mount API To: "Theodore Y. Ts'o" Cc: Andy Lutomirski , Al Viro , David Howells , Linus Torvalds , Linux FS Devel , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Aug 24, 2018 at 10:56 AM, Miklos Szeredi wrote: > On Fri, Aug 24, 2018 at 10:38 AM, Miklos Szeredi wrote: >> On Fri, Aug 24, 2018 at 8:05 AM, Theodore Y. Ts'o 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