On Thu, 2024-10-17 at 17:09 +0000, Trond Myklebust wrote: > On Thu, 2024-10-17 at 13:05 -0400, Jeff Layton wrote: > > On Thu, 2024-10-17 at 11:15 -0400, Paul Moore wrote: > > > On Thu, Oct 17, 2024 at 10:58 AM Christoph Hellwig > > > <hch@xxxxxxxxxxxxx> wrote: > > > > On Thu, Oct 17, 2024 at 10:54:12AM -0400, Paul Moore wrote: > > > > > Okay, good to know, but I was hoping that there we could come > > > > > up with > > > > > an explicit list of filesystems that maintain their own private > > > > > inode > > > > > numbers outside of inode-i_ino. > > > > > > > > Anything using iget5_locked is a good start. Add to that file > > > > systems > > > > implementing their own inode cache (at least xfs and bcachefs). > > > > > > Also good to know, thanks. However, at this point the lack of a > > > clear > > > answer is making me wonder a bit more about inode numbers in the > > > view > > > of VFS developers; do you folks care about inode numbers? I'm not > > > asking to start an argument, it's a genuine question so I can get a > > > better understanding about the durability and sustainability of > > > inode->i_no. If all of you (the VFS folks) aren't concerned about > > > inode numbers, I suspect we are going to have similar issues in the > > > future and we (the LSM folks) likely need to move away from > > > reporting > > > inode numbers as they aren't reliably maintained by the VFS layer. > > > > > > > Like Christoph said, the kernel doesn't care much about inode > > numbers. > > > > People care about them though, and sometimes we have things in the > > kernel that report them in some fashion (tracepoints, procfiles, > > audit > > events, etc.). Having those match what the userland stat() st_ino > > field > > tells you is ideal, and for the most part that's the way it works. > > > > The main exception is when people use 32-bit interfaces (somewhat > > rare > > these days), or they have a 32-bit kernel with a filesystem that has > > a > > 64-bit inode number space (NFS being one of those). The NFS client > > has > > basically hacked around this for years by tracking its own fileid > > field > > in its inode. That's really a waste though. That could be converted > > over to use i_ino instead if it were always wide enough. > > > > It'd be better to stop with these sort of hacks and just fix this the > > right way once and for all, by making i_ino 64 bits everywhere. > > Nope. > > That won't fix glibc, which is the main problem NFS has to work around. > True, but that's really a separate problem. It also doesn't inform how we track inode numbers inside the kernel. Inode numbers have been 64 bits for years on "real" filesystems. If we were designing this today, i_ino would be a u64, and we'd only hash that down to 32 bits when necessary. -- Jeff Layton <jlayton@xxxxxxxxxx>
