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

["Darrick J. Wong" <djwong@kernel.org>]

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

You're a filesystem maintainer.  Part of that work involves watching
fsdevel for VFS changes that affect the filesystems that you maintain.
From MAINTAINERS:

FILESYSTEMS (VFS and infrastructure)
L:      linux-fsdevel@vger.kernel.org

Demanding that everyone remember to cc you personally on every single
change to the VFS is not going to work.  That's why mailing lists exist.

> so that they at least get to raise concerns. Disclosing these
> news to a limited set of mailing lists only is not okay.

"Limited", e.g. the very list that people are supposed to use for
the two filesystems that you maintain?

HFS FILESYSTEM
L:      linux-fsdevel@vger.kernel.org

HFSPLUS FILESYSTEM
L:      linux-fsdevel@vger.kernel.org

IDGI.

--D