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 am not sure it is really needed. > > On second thought, maybe getting different events on the > same subvol with different fsid is not that bad, because for > btrfs, it is possible to resolve the path of an fid in subvol > from either the root mount or the subvol mount. > IOW, subvol_fsid+fid and root_fsid+fid are two ways to > describe the same unique object. > > Remember that we have two use cases for fsid+fid: > 1. (unpriv/priv) User queries fsid+fid, sets an inode mark on path, > stores fsid+fid<->path in a map to match events to path later > 2. (priv-only) User queries fsid, sets a sb/mount mark on path, > stores fsid<->path to match event to mntfd and > resolves path by handle from mntfd+fid You're right that for open_by_handle_at() the fsid is actually only good for getting *any* path on the superblock where file handle can be used so any of the fsids provided by btrfs is OK. What will be a slight catch is that if you would be using name_to_handle_at() to match what you've got from fanotify you will never be able to identify some fids. I'm not sure how serious that would be... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
