On Wed, Mar 24, 2021 at 11:18:36AM +0200, Amir Goldstein wrote:

On Wed, Mar 24, 2021 at 9:43 AM Christoph Hellwig [off-list ref] wrote:

quoted

On Wed, Mar 24, 2021 at 08:53:25AM +0200, Amir Goldstein wrote:

quoted

quoted

This also means that userspace can be entirely filesystem agnostic
and it doesn't need to rely on parsing proc files to translate
ephemeral mount IDs to paths, statvfs() and hoping that f_fsid is
stable enough that it doesn't get the destination wrong.  It also
means that fanotify UAPI probably no longer needs to supply a
f_fsid with the filehandle because it is built into the
filehandle....

That is one option. Let's call it the "bullet proof" option.

Another option, let's call it the "pragmatic" options, is that you accept
that my patch shouldn't break anything and agree to apply it.

Your patch may very well break something.  Most Linux file systems do
store the dev_t in the fsid and userspace may for whatever silly
reasons depend on it.

I acknowledge that.
I do not claim that my change carries zero risk of breakage.
However, if such userspace dependency exists, it would break on ext4,
btrfs, ocsf2, ceph and many more fs, so it would have to be a
dependency that is tightly coupled with a specific fs.
The probability of that is rather low IMO.

I propose an opt-in mount option "-o fixed_fsid" for this behavior to make
everyone sleep better.

Layering hacks on top of hacks to avoid fixing the fanotify UAPI
limitations isn't a very palatable option. Especially those that
require adding mount options we'll have to support forever more...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com