On Mon, Mar 11, 2024 at 06:30:21AM +0100, Miklos Szeredi wrote: > On Mon, 11 Mar 2024 at 03:17, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > On Fri, Mar 08, 2024 at 08:56:33AM -0800, Darrick J. Wong wrote: > > > Should the XFS data and rt volumes be reported with different stx_vol > > > values? > > > > No, because all the inodes are on the data volume and the same inode > > can have data on the data volume or the rt volume. i.e. "data on rt, > > truncate, clear rt, copy data back into data dev". It's still the > > same inode, and may have exactly the same data, so why should change > > stx_vol and make it appear to userspace as being a different inode? > > Because stx_vol must not be used by userspace to distinguish between > unique inodes. To determine if two inodes are distinct within a > filesystem (which may have many volumes) it should query the file > handle and compare that. > > If we'll have a filesystem that has a different stx_vol but the same > fh, all the better. I agree that stx_vol should not be used for uniqueness testing, but that's a non sequitar here; Dave's talking about the fact that volume isn't a constatn for a given inode on XFS. And that's a good point; volumes on XFS don't map to the filesystem path heirarchy in a nice clean way like on btrfs and bcachefs (and presumably ZFS). Subvolumes on btrfs and bcachefs form a tree, and that's something we should document about stx_subvol - recursively enumerable things are quite nice to work with.
