Re: [PATCH 0/3] fanotify support for btrfs sub-volumes

Christian Brauner
2023-11-08T16:16:38Z

On Wed, Nov 08, 2023 at 06:08:09AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 08, 2023 at 09:27:44AM +0100, Christian Brauner wrote:
> > > What is that flag going to buy us?
> >
> > The initial list that Josef provided in
> > https://lore.kernel.org/linux-btrfs/20231025210654.GA2892534@perftesting
> > asks to give users a way to figure out whether a file is located on a
> > subvolume. Which I think is reasonable and there's a good chunk of
> > software out there that could really benefit from this. Now all of the
> > additional info that is requested doesn't need to live in statx(). But
> > that flag can serve as an indicator for userspace that they are on a
> > subvolume and that they can go to btrfs specific ioctls if they want to
> > figure out more details.
>
> Well, if we want to legitimize the historic btrfs behavior the way to
> find out is if st_dev changes without that being a mount point, so
> an extra flag would be redundant.

The device number may also change on overlayfs per directory in certain
circumstances so it doesn't work in the general case.

Plus that requires a lot of gymnastics in the general case as you need
to statx() the file, call statfs() to figure out that it is a btrfs
filesystem, retrieve the device number of the superblock/filesystem and
compare that with the device number returned from stat(). And that's the
btrfs specific case. For bcachefs this doesn't work because it doesn't
seem to change st_dev.