On Wed, Nov 08, 2023 at 12:08:14PM +0100, Jan Kara wrote: > On Tue 07-11-23 23:51:58, Christoph Hellwig wrote: > > On Mon, Nov 06, 2023 at 05:42:10PM -0500, Josef Bacik wrote: > > > Again, this is where I'm confused, because this doesn't change anything, we're > > > still going to report st_dev as being different, which is what you hate. > > > > It's not something I hate. It's that changing it without a mount point > > has broken things and will probably still break things. > > So let me maybe return to what has started this thread. For fanotify we > return <fsid, fhandle> pair with events to identify object where something > happened. The fact that fsid is not uniform for all inodes of a superblock > on btrfs is what triggered this series because we are then faced with the > problem that caching fsid per superblock for "superblock marks" (to save > CPU overhead when generating events) can lead to somewhat confusing results > on btrfs. Whether we have vfsmount in the places where inodes' st_dev / > fsid change is irrelevant for this fanotify issue. As far as I'm following > the discussion it seems the non-uniform fsids per superblock are going to > stay with us on btrfs so fanotify code should better accommodate them? At > least by making sure the behavior is somewhat consistent and documented... I'd say if you want fanotify to work properly you must not switch st_dev and diverge from the known behavior. Just like your already do for tons of other things that use sb->s_dev or identifier derived from it as we've got plenty of those.
