On Tue, Dec 12, 2023 at 05:30:23PM +0100, Miklos Szeredi wrote: > On Tue, 12 Dec 2023 at 17:08, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > In short, STATX_ATTR_INUM_NOT_UNIQUE is required to tell userspace when > > they _must_ do the new thing if they care about correctness; it provides > > a way to tell userspace what guarantees we're able to provide. > > That flag would not help with improving userspace software. I disagree. Just having it there and in the documentation will be a good solid nudge to userspace programmers that this is something they need to consider. And: if we size this thing for NFSv4 filehandles, those are big: there's an overhead associated with using those, since userspace generally has to track in memory all inode numbers/file handles that it's seen. STATX_ATTR_INUM_NOT_UNIQUE would allow userspace to avoid that overhead when it is safe to do so. (But remember that file handles include inode generation numbers, and inode numbers do not; that is something we should remember to document, and explain why it is important). > What would help, if said software started using a unique identifier. > We already seem to have a unique ID in the form of file handles, > though some exotic filesystems might allow more than one fh to refer > to the same inode, so this still needs some looking into. > > The big problem is that we can't do a lot about existing software, and > must keep trying to keep st_ino unique for the foreseeable future. Whatever hacks we try to apply to st_ino are outside the scope of this discussion. Right now, we need to be figuring out what our future proofed interface is going to be, so that we don't end up kicking this can down the road when st_ino will be _really_ space constrained.
