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

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.

Also trying to use the fsid for anything persistent is plain stupid,
64-bits are not enough entropy for such an identifier.  You at least
need a 128-bit UUID-like identifier for that.

So I think this whole discussion is going in the wrong direction.
Is exposing a stable file system identifier useful?  Yes, for many
reasons.  Is repurposing the fsid for that a good idea?  Hell no.