On Wed, Nov 08, 2023 at 05:16:32PM +0100, Christian Brauner wrote: > > 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. Why would you care about the device of the super block? You need to compare it with the parent. > For bcachefs this doesn't work because it doesn't > seem to change st_dev. Well, that's going to be really broken then. But hey, if we merge these kinds of things without review we'll have to live ith it :( But maybe we just need to throw in the towel when we have three file systems now that think they can just do random undocument and not backward compatbile things with their inode numbers and declare the inode number of a compeltely meaningless cookie..
