Re: [LSF TOPIC] statx extensions for subvol/snapshot filesystems & more

[Miklos Szeredi <miklos@szeredi.hu>]

On Thu, 22 Feb 2024 at 10:42, Kent Overstreet <kent.overstreet@linux.dev> 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