Re: [LSF/MM/BPF TOPIC] Should we make inode->i_ino a u64?

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

On Wed, 2026-04-15 at 06:44 -0700, Jeff Layton wrote:
> You're pointing me at Phoronix and complaining about clear
> communication? That headline is made to generate clicks. It doesn't
> represent the reality.

Well, your own justification was that 32-bit architectures will be killed
anyway in the future, so it's okay if they are affected by a negative
impact:

> > I think that the biggest problem will be that this will grow struct
> > inode on 32-bit arches by at least 4 bytes. That may have cacheline
> > alignment and slab sizing implications. We're actively talking about
> > deprecating 32-bit arches in the future however, so maybe we can
> > rationalize that away.

> The mention of potential performance impact on 32 bit hosts is entirely
> speculative and not likely to be measurable anywhere. I only mentioned
> it at all in the interest of full disclosure.

It didn't sound like that when you argued it won't be problem because they're
going way. If you think it's not going to be a real impact, why even bring
up the argument that it will only affect targets that "we" want to get rid of?

> We're widening the i_ino field from 32 to 64 bits on 32-bit hosts. This
> means that we're adding 4 more bytes to every inode there. Sounds bad
> right? 

That's not the point here though. Please re-read your own argument.

Phoronix's headline might be somewhat clickbait, but it's not a complete
misrepresentation of what you wrote.

> The reality is more complicated...
> 
> struct inode is (almost) always embedded in another structure that
> contains the fs-specific fields for it. Many of those (nfs, xfs, etc.)
> have had to carry a separate 64 bit field to hold the "real" inode
> number since we couldn't count on i_ino being big enough on 32-bit
> arches.
> 
> Those fields can now go away, and once they do, that will represent a
> 4-byte _reduction_ in size of the inode on those filesystems. So there
> are potential upsides here for 32-bit arches as well.

Then why not mention this? Why communicate a message that seems to imply
that performance will be degraded on 32-bit targets?

> The bottom line is that we add and remove fields in struct inode all
> the time. It grows and shrinks as we do this. This change will almost
> certainly not be measurable anywhere.

I'm not arguing against that. All that I am saying that I am not happy when
a change is communicated within a small audience with the assumption that
no one will care. I mean, if you don't notify the audience that might be
affected by the change, it's a self-fulfilling prophecy that you won't hear
from them.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913