Christian Brauner wrote:
> > There is a upcoming potential problem where even the 64-bit field I placed
> > in statx() may be insufficient. The Auristor AFS server, for example, has
> > a 96-bit vnode ID, but I can't properly represent this in stx_ino.
> > Currently, I
>
> Is that vnode ID
Christian Brauner wrote:
> > > > I suggest:
> > > >
> > > > STATX_ATTR_INUM_NOT_UNIQUE - it is possible that two files have the
> > > > same inode number
>
> This is just ugly with questionable value. A constant reminder of how
> broken this is. Exposing the
Dave Chinner wrote:
> I mean, we already have name_to_handle_at() for userspace to get a
> unique, opaque, filesystem defined file handle for any given file.
> It's the same filehandle that filesystems hand to the nfsd so nfs
> clients can uniquely identify the file they are asking the nfsd to
>
NeilBrown wrote:
> I'm not in favour of any filesystem depending on this for correct
> functionality today. As long as the filesystem isn't so large that
> inum+volnum simply cannot fit in 64 bits, we should make a reasonable
> effort to present them both in 64 bits.
The Auristor version of
Kent Overstreet 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
