On Mon, Dec 11, 2023 at 11:40:16PM +0000, David Howells wrote: > Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > I was chatting a bit with David Howells on IRC about this, and floated > > adding the file handle to statx. It looks like there's enough space > > reserved to make this feasible - probably going with a fixed maximum > > size of 128-256 bits. > > We can always save the last bit to indicate extension space/extension record, > so we're not that strapped for space. So we'll need that if we want to round trip NFSv4 filehandles, they won't fit in existing struct statx (nfsv4 specs 128 bytes, statx has 96 bytes reserved). Obvious question (Neal): do/will real world implementations ever come close to making use of this, or was this a "future proofing gone wild" thing? Say we do decide we want to spec it that large: _can_ we extend struct statx? I'm wondering if the userspace side was thought through, I'm sure glibc people will have something to say. Kernel side we can definitely extend struct statx, and we know how many bytes to copy to userspace because we know what fields userspace requested. The part I'm concerned about is that if we extend userspace's struct statx, that introduces obvious ABI compabitibility issues. So this would probably force glibc to introduce a new version of struct statx, if I'm not mistaken. Or: another option would be to reserve something small and sane in struct statx (32 bytes max, I'd say), and then set a flag to tell userspace they need to use name_to_handle_at() if it didn't fit.
