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
