Re: [RFC][PATCH] fanotify: Enable FAN_REPORT_FID on more filesystem types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 20, 2023 at 7:36 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Wed 20-09-23 18:12:00, Amir Goldstein wrote:
> > On Wed, Sep 20, 2023 at 4:48 PM Jan Kara <jack@xxxxxxx> 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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux