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

[Jeff Layton <jlayton@kernel.org>]

On Wed, 2026-04-15 at 11:11 +0200, John Paul Adrian Glaubitz wrote:
> Hello,
> 
> On Wed, 2026-02-18 at 10:36 -0500, Jeff Layton wrote:
> > For historical reasons, the inode->i_ino field is an unsigned long.
> > Because it's only 32 bits on 32-bit CPUs, this has caused a lot of fs-
> > specific hacks on filesystems that have native 64-bit inode numbers
> > when running a 32-bit arch.
> > 
> > It would be a lot simpler if we just converted i_ino to be 64-bits and
> > dealt with the conversion at the kernel's edges. This would be a non-
> > event for the most part on 64-bit arches since unsigned long is already
> > 64 bits there.
> > 
> > The kernel itself doesn't deal much with i_ino, so the internal changes
> > look fairly straightforward. The bulk of the patches will be to format
> > strings and to tracepoints.
> > 
> > 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.
> > 
> > FWIW, I had Claude spin up a plan to do this (attached). It's not bad.
> > I'm tempted to tell it generate patches for this, since this is mostly
> > a mechanical change, but I'm curious whether anyone else might have
> > reasons that we shouldn't go ahead and do it.
> 
> So, this went just over Phoronix [1] and as someone who is still invested
> in 32-bit architectures, I'm only notified about the performance impact on
> these systems now as the pull request has already been sent to Linus.
> 
> I'm frustrated by this poor communication style. If your change affects certain
> users negatively, it should be openly communicated to them on the appropriate
> mailing lists so that they at least get to raise concerns. Disclosing these
> news to a limited set of mailing lists only is not okay.
> 
> Thanks,
> Adrian
> 
> > [1] https://www.phoronix.com/news/Linux-7.1-VFS-Kino-32-bit

You're pointing me at Phoronix and complaining about clear
communication? That headline is made to generate clicks. It doesn't
represent the reality.

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.

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? 

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.

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.
-- 
Jeff Layton <jlayton@kernel.org>