Fold the server's 128bit fsid to report f_fsid in statfs(2). This is similar to how uuid is folded for f_fsid of ext2/ext4/zonefs. This allows nfs client to be monitored by fanotify filesystem watch for local client access if nfs supports re-export. For example, with inotify-tools 4.23.8.0, the following command can be used to watch local client access over entire nfs filesystem: fsnotifywatch --filesystem /mnt/nfs Note that fanotify filesystem watch does not report remote changes on server. It provides the same notifications as inotify, but it watches over the entire filesystem and reports file handle of objects and fsid with events. Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> --- Anna, Trond, I realize that the value of watching local changes without getting notifications on remote changes is questionable, but still, we want fanotify to be on-par with inotify in that regard. Remote notification via fanotify has been requested in the past for fuse and for smb3. If we ever implement those, they will most likely require a new opt-in flag to fanotify. I think that exporting a digest of the server's fsid via statfs(2) on the client mounts is useful regardless of fanotify, so please consider this change to NFS client. Thanks, Amir. fs/nfs/super.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 0d6473cb00cb..d0f41f53b795 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -295,6 +295,7 @@ int nfs_statfs(struct dentry *dentry, struct kstatfs *buf) buf->f_ffree = res.afiles; buf->f_namelen = server->namelen; + buf->f_fsid = u64_to_fsid(server->fsid.major ^ server->fsid.minor); return 0; -- 2.34.1
