On Thu, Feb 22, 2024 at 11:25:12AM +0100, Miklos Szeredi wrote: > 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. You say "creating good interfaces is never easy" - but we've got a proposal, that's bounced around a fair bit, and you aren't saying anything concrete. > > We need something better than "hacks". > > That's the end goal, obviously. But we also need to take care of > legacy. Always have. So what are you proposing? > > 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. Didn't you see Josef just say they're trying to get away from st_dev? > 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. No, I explicitly said that when INO_NOT_UNIQUE is set the _filehandle_ would be the means to identify the file.
