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

On Fri, 2026-04-17 at 10:34 +0200, John Paul Adrian Glaubitz 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?
> 
> 

Others have already addressed your other points, so I won't bother, but
for this one...

At the time I was writing the patches, I was thinking mostly about the
linux-fsdevel@ audience. Any change to the kernel _always_ comes with
tradeoffs and I've found it's best to be straightforward about the
potential downsides of any change.

I probably should have made more clear that the potential downsides in
this case were almost certainly not measurable. Mea culpa.
-- 
Jeff Layton <[email protected]>