On Mon, Oct 14, 2024 at 04:45:00PM +0200, Christian Brauner wrote: > On Sun, Oct 13, 2024 at 06:17:43AM -0400, Jeff Layton wrote: > > On Fri, 2024-10-11 at 17:30 +0200, Mickaël Salaün wrote: > > > On Fri, Oct 11, 2024 at 07:39:33AM -0700, Christoph Hellwig wrote: > > > > On Fri, Oct 11, 2024 at 03:52:42PM +0200, Mickaël Salaün wrote: > > > > > > > Yes, but how do you call getattr() without a path? > > > > > > > > > > > > You don't because inode numbers are irrelevant without the path. > > > > > > > > > > They are for kernel messages and audit logs. Please take a look at the > > > > > use cases with the other patches. > > > > > > > > It still is useless. E.g. btrfs has duplicate inode numbers due to > > > > subvolumes. > > > > > > At least it reflects what users see. > > > > > > > > > > > If you want a better pretty but not useful value just work on making > > > > i_ino 64-bits wide, which is long overdue. > > > > > > That would require too much work for me, and this would be a pain to > > > backport to all stable kernels. > > > > > > > Would it though? Adding this new inode operation seems sub-optimal. > > I agree. Of course it would be better to fix the root of the issue. Who is up for the challenge? > > > Inode numbers are static information. Once an inode number is set on an > > inode it basically never changes. This patchset will turn all of those > > direct inode->i_ino fetches into a pointer chase for the new inode > > operation, which will then almost always just result in a direct fetch. > > Yup. > > > A better solution here would be to make inode->i_ino a u64, and just > > fix up all of the places that touch it to expect that. Then, just > > I would like us to try and see to make this happen. I really dislike > that struct inode is full of non-explicity types. Also, it would be OK to backport it, right?
