On Tue, 12 Dec 2023 at 10:23, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Tue, Dec 12, 2023 at 09:10:47AM +0000, David Howells wrote: > > Christian Brauner <brauner@xxxxxxxxxx> 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 subvolume id also makes this somewhat redundant. > > > > 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 akin to a volume? Because if so you could just > piggy-back on a subvolume id field in statx() and expose it there. And how would exporting a subvolume ID and expecting userspace to take that into account when checking for hard links be meaningfully different than expecting userspace to retrieve the file handle and compare that? The latter would at least be a generic solution, including stacking fs inodes, instead of tackling just a specific corner of the problem space. Thanks, Miklos
