On Fri, Mar 26, 2021 at 10:15 PM J. Bruce Fields [off-list ref] wrote:

On Tue, Mar 23, 2021 at 06:50:44AM +0200, Amir Goldstein wrote:

quoted

On Tue, Mar 23, 2021 at 1:03 AM Dave Chinner [off-list ref] wrote:

quoted

should be using something common across all filesystems from the
linux superblock, not deep dark internal filesystem magic. The
export interfaces that generate VFS (and NFS) filehandles already
have a persistent fsid associated with them, which may in fact be
the filesystem UUID in it's entirety.

Yes, nfsd is using dark internal and AFAIK undocumnetd magic to
pick that identifier (Bruce, am I wrong?).

Sorry, I kept putting off catching up with this thread and only now
noticed the question.

It's actually done mostly in userspace (rpc.mountd), so "dark internal"
might not be fair, but it is rather complicated.  There are several
options (UUID, device number, number provided by the user with fsid=
option), and I don't recall the logic behind which we use when.

I'll take back "dark internal" then and replace it with "light external" ;-)
which is also a problem. If userspace is involved in declaring the id
of the *export* then from NFS client POV, that is not a problem, but
from fsnotify POV, that identifier cannot be determined when an event
happens on an inode NOT via the NFS client.

As a matter of fact, the fanotify requirements about fsid are even more
strict than being able to get fsid from the inode. From fanotify_mark.2:
"
       EXDEV  The filesystem object indicated by pathname resides within
              a filesystem subvolume (e.g., btrfs(5)) which uses a
different fsid
              than its root superblock...
"

I don't *think* we have good comprehensive documentation of it anywhere.
I wish we did.  It'd take a little time to put together.  Starting
points would be linux/fs/nfsd/nfsfh.c and
nfs-utils/support/export/cache.c.

At least as far as fanotify is concerned, the documentation is not going
to matter. The only thing needed is an fsid value that is queryable via
a userspace API.

f_fsid meets this criteria, which is why it was chosen for fanotify.
Having the fsid reported by fanotify also be stable is a nice to have
feature for very selective use cases, which is why I posted this xfs patch.

Thanks,
Amir.