Re: [git pull] new mount API

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

 



On Fri, Aug 24, 2018 at 8:05 AM, Theodore Y. Ts'o <tytso@xxxxxxx> 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?

No, I don't think this argument is about the mount(8) interface, which
is what the sysadmin is using and can continue to use for the
foreseeable future, with basically the same feature set

It's about new uses of the mount(2) API  that *would* be possible if
it was a saner interface.   And so doing the new mount API radically
different than what current mount(2) is doing is quite all right in my
opinion.

> It may very well be that the "cleaner" approach will be hellacious
> from a human usability perspective.  Figuring all of this out could
> take months and months (stalling the new mount API for a long time),
> and we may never know for sure until we implement a full prototype of
> kernel changes, massive rewrite of the file systems, and userspace
> programs --- and then see what is the best way to expose the radically
> different semantics depending on what individual file systems can and
> can not do to the poor human system administrator who is just trying
> to mount the d*mned file system.

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), but it may make sense to
differentiate the legacy behavior from a saner one from the very
start.  I.e. rename FSCONFIG_CMD_CREATE 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).

Also, we don't have a massive conversion of filesystems yet to the new
internal API, so we could require anything converted to support the
exclusive create semantics.

None of this requires months of figuring out, just a bit of tweaking
and acknowledging that the current semantics are weird, to say the
least.

Thanks,
Miklos



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

  Powered by Linux