On Wed, 13 Dec 2023, Kent Overstreet wrote:
> On Wed, Dec 13, 2023 at 09:57:22AM +1100, NeilBrown wrote:
> > 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.
>
> The trouble is that C has no notion of which types are safe to pass
> across a dynamic library boundary, so if we increase the size of struct
> statx and someone's doing that things will break in nasty ways.
>
Maybe we don't increase the size of struct statx.
Maybe we declare
struct statx2 {
struct statx base;
__u8 stx_handle[128];
}
and pass then when we request STX_HANDLE.
Or maybe there is a better way. I'm sure the glibc developers have face
this sort of problem before.
NeilBrown
