Jan, This patch set implements your suggestion [1] for handling fanotify events for filesystems with non-uniform f_fsid. With these changes, events report the fsid as it would be reported by statfs(2) on the same objet, i.e. the sub-volume's fsid for an inode in sub-volume. This creates a small challenge to watching program, which needs to map from fsid in event to a stored mount_fd to use with open_by_handle_at(2). Luckily, for btrfs, fsid[0] is uniform and fsid[1] is per sub-volume. I have adapted fsnotifywatch tool [2] to be able to watch btrfs sb. The adapted tool detects the special case of btrfs (a bit hacky) and indexes the mount_fd to be used for open_by_handle_at(2) by fsid[0]. Note that this hackacry is not needed when the tool is watching a single filesystem (no need for mount_fd lookup table), because btrfs correctly decodes file handles from any sub-volume with mount_fd from any other sub-volume. Christian is targeting the patches on vfs.f_fsid to the second part of the 6.7 merge window. If I get an ACK from you and from btrfs developers, perhaps these patches could also make it to 6.7. The btrfs patch could go independently via btrfs tree after the vfs patch is merged, as does the fanotify patch, but it is my preference to get ACKs and queue them all in the same vfs PR. Thanks, Amir. [1] https://lore.kernel.org/r/20230920110429.f4wkfuls73pd55pv@quack3/ [2] https://github.com/amir73il/inotify-tools/commits/exportfs_encode_fid Amir Goldstein (3): fs: define a new super operation to get fsid btrfs: implement super operation to get fsid fanotify: support reporting events with fid on btrfs sub-volumes Documentation/filesystems/locking.rst | 2 ++ Documentation/filesystems/vfs.rst | 4 ++++ fs/btrfs/super.c | 33 ++++++++++++++++++--------- fs/notify/fanotify/fanotify.c | 28 +++++++++++++++++------ fs/notify/fanotify/fanotify_user.c | 14 ++++++++---- fs/statfs.c | 14 ++++++++++++ include/linux/fs.h | 1 + include/linux/statfs.h | 2 ++ 8 files changed, 76 insertions(+), 22 deletions(-) -- 2.34.1
