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
