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

On Wed, Apr 15, 2026 at 11:11:32AM +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.

* You're linking to a Phoronix article as prove that there's a
  performance impact.

* You're complaining that you haven't been Cced even though you
  seemingly maintain mutliple filesystems that have their ML set to
  fsdevel.

* You're trying to mandate what very valuable internal VFS changes we
  get to make based on 32-bit concerns.

I don't see a single coherent argument in this list worth engaging with
- especially with that lamenting tone.

Suggestions for next time:

"I just read this article on Phoronix that mentions a potential
performance impact on 32-bit systems. Is that valid or do you think this
is going to not be an issue?"

I get that you care about 32-bit and legacy hardware a lot. But upstream
Linux has clarified multiple times that we don't jump through any extra
hoops for 32-bit anymore. This is especially true if the claimed perf
regressions so far are purely theoretical.

I don't think there's anything actionable for us here at all. Thanks
again, @Jeff for doing this work we've been talking about for multiple
years. It was about time.