On Thu, 22 Feb 2024 at 10:42, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > Yeah no, you can't crap multiple 64 bit inode number spaces into 64 > bits: pigeonhole principle. Obviously not. And I have no idea about the inode number allocation strategy of bcachefs and how many bits would be needed for subvolumes, etc.. I was just telling what overlayfs does and why. It's a pragmatic solution that works. I'd very much like to move to better interfaces, but creating good interfaces is never easy. > We need something better than "hacks". That's the end goal, obviously. But we also need to take care of legacy. Always have. > This isn't a serious proposal. If not, then what is? BTW to expand on the st_dev_v2 idea, it can be done by adding a STATX_DEV_V2 query mask. That way userspace can ask for the uniform stx_dev if it wants, knowing full well that stx_ino will be non-unique within that filesystem. Then kernel is free to return with or without STATX_DEV_V2, which is basically what you proposed. Except it's now negotiated and not forced upon legacy interfaces. The other issue is adding subvolume ID. You seem to think that it's okay to add that to statx and let userspace use (st_ino, st_subvoid) to identify the inode. I'm saying this is wrong, because it doesn't work in the general case. It doesn't work for overlayfs, for example, and we definitely want to avoid having userspace do filesystem specific things *if it isn't absolutely necessary*. So for example "tar" should not care about subvolumes as long as it's not been explicitly told to care. And that means for hard link detection if should using the file handle + st_dev_v2 instead of st_ino + st_subvolid + st_dev_v2. So if that field is added to statx it must come with a stern warning about this type of usage. Thanks, Miklos
