On Thu, Aug 16, 2018 at 12:06:06AM -0500, Eric W. Biederman wrote: > So I don't think we can completely abandon the option for filesystems > to always create a new filesystem instance when mount(8) is called. Huh? If filesystem wants to create a new instance on each ->mount(), it can bloody well do so. Quite a few do - if that fs can handle that, more power to it. The problem is what to do with filesystems that *can't* do that. You really, really can't have two ext4 (or xfs, etc.) instances over the same device at the same time. Cache coherency, locking, etc. will kill you. And that's not to mention the joy of defining the semantics of having the same ext4 mounted with two logs at the same time ;-) I've seen "reject unless the options are compatible/identical/whatever", but that ignores the real problem with existing policy. It's *NOT* "I've mounted this and got an existing instance with non-matching options". That's a minor annoyance (and back when that decision had been made, mount(2) was very definitly root-only). The real problem is different and much worse - it's remount. I have asked to mount something and it had already been mounted, with identical options. OK, so what happens if I do mount -o remount on my instance? *IF* we are operating in the "only sysadmin can mount new filesystems", it's not a big deal - there are already lots of ways you can shoot yourself in the foot and mount(2) is certainly a powerful one. But if we get to "Joe R. Luser can do it in his container", we have a big problem. Decision back then had been mostly for usability reasons - it was back in 2001 (well before the containermania, userns or anything of that sort) and it was more about "how many hoops does one have to jump through to get something mounted, assuming the sanity of sysadmin doing that?". If *anything* like userns had been a concern back then, it probably would've been different. However, it's 17 years too late and if anyone has a functional TARDIS, I can easily think of better uses for it...
