On Wed, 13 Dec 2023, Kent Overstreet wrote:
> On Mon, Dec 11, 2023 at 11:40:16PM +0000, David Howells wrote:
> > Kent Overstreet <[email protected]> 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?
I have no useful data. I have seen lots of filehandles but I don't pay
much attention to their length. Certainly some are longer than 32 bytes.
>
> 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.
The man page says:
Therefore, do not simply set mask to UINT_MAX (all bits set), as
one or more bits may, in the future, be used to specify an
extension to the buffer.
I suspect the glibc people read that.
NeilBrown
>
> 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.
>
