Linux NFS development
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Trond Myklebust <trond.myklebust@hammerspace.com>,
	Anna Schumaker <anna@kernel.org>,
	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-unionfs@vger.kernel.org,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH] fuse: derive f_fsid from s_dev and connection start time
Date: Wed, 25 Oct 2023 16:21:54 +0200	[thread overview]
Message-ID: <20231025142154.witld2g5iici24fr@quack3> (raw)
In-Reply-To: <20231025114228.23167-1-amir73il@gmail.com>

On Wed 25-10-23 14:42:28, Amir Goldstein wrote:
> Use s_dev number and connection start time to report f_fsid in statfs(2).
> 
> The s_dev number could be easily recycled, so we use lower 32bits of the
> connection start time to try to avoid the recycling of f_fsid.
> The anon bdev number is only 20 bits (major is 0), so we could use more
> bits from connection start time, but avoiding f_fsid recycling is not
> critical, so 32bit is enough.
> 
> If the server does not support NFS export, fuse client still advertizes
> ->s_export_op, but those are non compliant operations that often cannot
> decode file handles, or worse, decode file hanldes to wrong objects.
> 
> In this case, leave f_fsid zero to signal fanotify and aware users to
> avoid exporting this incompliant fuse filesystem to NFS.
> 
> This allows fuse client to be monitored by fanotify filesystem watch
> for local client file access if server supports NFS 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/fuse
> 
> 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>
> ---
> 
> Miklos,
> 
> I'd like to explain why I chose to tie setting fuse f_fsid with fuse
> server NFS export capability.
> 
> Since v6.6-rc7, fanotify permits sb/mount watch only for filesystems
> that know how to decode ALL file handles (not only how to encode).
> fanotify checks for the ->fh_to_dentry() method, which fuse always
> implements regardless of server NFS export support.
> 
> At first I considered assigning s_export_op depending on server NFS
> export support, but that would break the exising fuse best-effort decode
> behavior, whatever it is worth.
> 
> Currently, fanotify sb watch does not support fuse because of zero f_fsid,
> so I decided to keep it this way for the incomplete NFS export case.

OK, so this will keep fanotify not able to support inotify functionality in
this corner case. I'm fine with that but I'm making sure I understand the
implications.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

      reply	other threads:[~2023-10-25 14:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25 11:42 [PATCH] fuse: derive f_fsid from s_dev and connection start time Amir Goldstein
2023-10-25 14:21 ` Jan Kara [this message]

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=20231025142154.witld2g5iici24fr@quack3 \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=anna@kernel.org \
    --cc=bcodding@redhat.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox