On Thu, 07 Dec 2023, Donald Buczek wrote: > > I'd vote for the subvol-id. I think, with bcachefs a u32 would do, > but it could be return as u64 for future growth or other filesystems.
Probably a good choice. Though I'd like to re-emphasise that even doing this doesn't remove the need to make sure inode numbers are as unique as they can possibly be made. There are multiple places in /proc (for example) where a file is identified by fsid and inode number. It isn't really practical to insert a volume-id in there (though maybe we could duplicate all those interfaces....). Inode numbers would need to be absolutely unique with a volume, and mostly unique within a filesystem. xor-ing the internal inode number with a hash of the volume number is one way to achieve this. i.e.: while enabling processes that use stat() family function is clearly import, it does not solve all the problems caused by the addition of a volume/subvol level between "filesystem" and "inode". Thanks, NeilBrown
