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.
