All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Trond Myklebust <trond.myklebust@hammerspace.com>,
	Anna Schumaker <anna@kernel.org>
Cc: Benjamin Coddington <bcodding@redhat.com>,
	Jeff Layton <jlayton@kernel.org>,
	Chuck Lever <chuck.lever@oracle.com>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: [PATCH v2] nfs: derive f_fsid from s_dev and server's fsid
Date: Wed, 25 Oct 2023 09:11:17 +0300	[thread overview]
Message-ID: <20231025061117.3068417-1-amir73il@gmail.com> (raw)

Use s_dev number and the server's fsid to report f_fsid in statfs(2).

The server's fsid could be zero for NFSv4 root export and is not unique
across different servers, so we use the s_dev number to avoid local
f_fsid collisions.

The s_dev number could be easily recycled, so we use a 32bit hash of the
server's fsid to try to avoid the recycling of same local f_fsid for
different remote fs.  The anon bdev number is only 20 bits (major is 0),
so we could use more bits for the server's fsid hash, but avoiding f_fsid
recycling is not critical, so 32bit hash is enough.

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@gmail.com>
---

Anna, Trond,

I have changed v2 according to feedback from Ben.

I would like to refer you to the documentation of f_fsid in statfs(2):

"Nobody knows what f_fsid is supposed to contain...
 The general idea is that f_fsid contains some random stuff such that the
 pair (f_fsid,ino) uniquely determines a file.  Some operating systems use
 (a variation on) the device number, or the device number combined with the
 filesystem type..."

This definition leaves a lot of room for interpretations.
I chose f_fsid format {dev_num, fsid_hash}, because I think that it nicely
extends f_fsid format {dev_num, 0}, used by many fs without persistent fsid.

Thanks,
Amir.

Changes since v1:
- Use d_sev number to avoid collisions (bcodding)

 fs/nfs/super.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 0d6473cb00cb..30bcd53da3bc 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -295,6 +295,15 @@ int nfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 	buf->f_ffree = res.afiles;
 
 	buf->f_namelen = server->namelen;
+	/*
+	 * Using the anon bdev number to avoid local f_fsid collisions.
+	 * Server's fsid could be zero for NFSv4 root export and is not unique
+	 * across different servers, but we use it as best effort to try to
+	 * avoid the recycling of same local f_fsid for different remote fs.
+	 */
+	buf->f_fsid.val[0] = new_encode_dev(server->s_dev);
+	buf->f_fsid.val[1] = hash_64(server->fsid.major, 32) ^
+			     hash_64(server->fsid.minor, 32);
 
 	return 0;
 
-- 
2.34.1


                 reply	other threads:[~2023-10-25  6:11 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231025061117.3068417-1-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=anna@kernel.org \
    --cc=bcodding@redhat.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.