From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Jeff Layton <jlayton@kernel.org>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [RFC][PATCH] fanotify: Enable FAN_REPORT_FID on more filesystem types
Date: Wed, 18 Oct 2023 21:35:30 +0300 [thread overview]
Message-ID: <CAOQ4uxjpMqzzgc--302n4Vc_PLO-RPppk65pSo6B_V-3XiK_Lw@mail.gmail.com> (raw)
In-Reply-To: <20230920163634.5agdx523uv7m2qtf@quack3>
On Wed, Sep 20, 2023 at 7:36 PM Jan Kara <jack@suse.cz> wrote:
>
> On Wed 20-09-23 18:12:00, Amir Goldstein wrote:
> > On Wed, Sep 20, 2023 at 4:48 PM Jan Kara <jack@suse.cz> wrote:
> > > > If users had a flag to statfs() to request the "btrfs root volume fsid",
> > > > then fanotify could also report the root fsid and everyone will be happy
> > > > because the btrfs file handle already contains the subvolume root
> > > > object id (FILEID_BTRFS_WITH_PARENT_ROOT), but that is not
> > > > what users get for statfs() and that is not what fanotify documentation
> > > > says about how to query fsid.
> > > >
> > > > We could report the subvolume fsid for marked inode/mount
> > > > that is not a problem - we just cache the subvol fsid in inode/mount
> > > > connector, but that fsid will be inconsistent with the fsid in the sb
> > > > connector, so the same object (in subvolume) can get events
> > > > with different fsid (e.g. if one event is in mask of sb and another
> > > > event is in mask of inode).
> > >
> > > Yes. I'm sorry I didn't describe all the details. My idea was to report
> > > even on a dentry with the fsid statfs(2) would return on it. We don't want
> > > to call dentry_statfs() on each event (it's costly and we don't always have
> > > the dentry available) but we can have a special callback into the
> > > filesystem to get us just the fsid (which is very cheap) and call *that* on
> > > the inode on which the event happens to get fsid for the event. So yes, the
> > > sb mark would be returning events with different fsids for btrfs. Or we
> > > could compare the obtained fsid with the one in the root volume and ignore
> > > the event if they mismatch (that would be more like the different subvolume
> > > => different filesystem point of view and would require some more work on
> > > fanotify side to remember fsid in the sb mark and not in the sb connector).
> > >
> >
> > It sounds like a big project.
>
> Actually it should be pretty simple as I imagine it. Maybe I can quickly
> hack a POC.
>
I think I get what you mean.
Pushed POC (only compile tested so far) to branch inode_fsid on my github [1]
and posted the patches for seamless support for non-decodable fid.
Let me know if that is what you meant.
Thanks,
Amir.
[1] https://github.com/amir73il/linux/commits/inode_fsid
next prev parent reply other threads:[~2023-10-18 18:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 12:40 [RFC][PATCH] fanotify: Enable FAN_REPORT_FID on more filesystem types Amir Goldstein
2023-04-12 18:43 ` Jan Kara
2023-04-13 9:25 ` Amir Goldstein
2023-04-17 16:27 ` Jan Kara
2023-09-20 8:26 ` Amir Goldstein
2023-09-20 10:27 ` Jeff Layton
2023-09-20 11:04 ` Jan Kara
2023-09-20 12:41 ` Amir Goldstein
2023-09-20 13:48 ` Jan Kara
2023-09-20 15:12 ` Amir Goldstein
2023-09-20 16:36 ` Jan Kara
2023-10-18 18:35 ` Amir Goldstein [this message]
2023-10-25 14:11 ` Amir Goldstein
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=CAOQ4uxjpMqzzgc--302n4Vc_PLO-RPppk65pSo6B_V-3XiK_Lw@mail.gmail.com \
--to=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).