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

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

[John Paul Adrian Glaubitz]

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

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

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

[Jeff Layton]

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>

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

[John Paul Adrian Glaubitz]

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

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

[Jeff Layton]

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

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

[Theodore Tso]

On Wed, Apr 15, 2026 at 11:11:32AM +0200, John Paul Adrian Glaubitz wrote:
>
> 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.

Adrian,

I note that you are a Debian Maintainer.  Like Debian, the Linux
kernel development community is very much a do-ocracy --- only more
so.  If the 32-bit community really cares about Linux support, they
need to be providing volunteer labor to kernel development, instead of
demanding that everyone else pay the overhead tax of supporting 32-bit
platforms which are rapidly disappearing.  I will note that Debian
itself has made the decision to stop supporting the Debian Installer
for i386 and the 32-bit armel platform in Debian Trixie.

Best regards,

					- Ted

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

[Kolbjørn Barmen]

On Wed, 15 Apr 2026, Theodore Tso wrote:

> Like Debian, the Linux kernel development community is very much a
> do-ocracy --- only more so.  If the 32-bit community really cares about
> Linux support, they need to be providing volunteer labor to kernel
> development, instead of demanding that everyone else pay the overhead
> tax of supporting 32-bit platforms which are rapidly disappearing.

This tells me that it is time for "the 32-bit community" (wtf) to either
look elsewhere, or start thinking of forking the Linux kernel perhaps
sooner rather than later, so we don't bother "the 64-bit community" so
much.

> I will note that Debian itself has made the decision to stop supporting
> the Debian Installer for i386 and the 32-bit armel platform in Debian Trixie.

Which is why (for example) Raspberry Pi is maintaining their own Raspberry Pi OS,
as they have 32-bit systems that aren't EOL for another 3-4 years.

-- kolla

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

[Geert Uytterhoeven]

Hi Kolbjørn,

On Fri, 24 Apr 2026 at 08:46, Kolbjørn Barmen <linux-m68k@kolla.no> wrote:
> On Wed, 15 Apr 2026, Theodore Tso wrote:
> > Like Debian, the Linux kernel development community is very much a
> > do-ocracy --- only more so.  If the 32-bit community really cares about
> > Linux support, they need to be providing volunteer labor to kernel
> > development, instead of demanding that everyone else pay the overhead
> > tax of supporting 32-bit platforms which are rapidly disappearing.
>
> This tells me that it is time for "the 32-bit community" (wtf) to either
> look elsewhere, or start thinking of forking the Linux kernel perhaps
> sooner rather than later, so we don't bother "the 64-bit community" so
> much.
>
> > I will note that Debian itself has made the decision to stop supporting
> > the Debian Installer for i386 and the 32-bit armel platform in Debian Trixie.

Note "armel", not "armhf".

> Which is why (for example) Raspberry Pi is maintaining their own Raspberry Pi OS,
> as they have 32-bit systems that aren't EOL for another 3-4 years.

https://lwn.net/Articles/1051010/:
"In 204x, support for the last 32-bit architectures would be removed."

However, by then they will have all run out of memory.
E.g. we recently got 64 (128 on 64-bit) KiB of "gaps", cfr.
https://lore.kernel.org/all/20260415190454.2632348-1-geert@linux-m68k.org

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Theodore Tso]

On Fri, Apr 24, 2026 at 08:38:56AM +0200, Kolbjørn Barmen wrote:
> 
> This tells me that it is time for "the 32-bit community" (wtf) to either
> look elsewhere, or start thinking of forking the Linux kernel perhaps
> sooner rather than later, so we don't bother "the 64-bit community" so
> much.

My point was that having people whine about a decision isn't a
particularly productive way to engage with the kernel development
community.  Especiually when the person who was complaining was the
HFS maintainer, and the mailing list that he *should* have been paying
attention to was linux-fsdevel, since it's marked as the primary list
where HFS bugs and development issues should be discussed, and
linux-fsdevel was one of the mailing lists where the 64-bit inode
proposal was cc'ed --- maybe that says something about how engaged he
*really* was with Linux Kernel development.

But hey, it's open source.  Forking is always allowed.  My guess is
that a fork would involve a stagnating code base that won't be to keep
up with bug fixes, including security bugs.  This is especially if
most people working on 32-bit architectures are as engaged as the OP.
Most forked projects don't end up working well, but everyone has the
right to find that out for themselves.

Cheers,

						- Ted

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

[Darrick J. Wong]

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

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

[Christoph Hellwig]

On Wed, Apr 15, 2026 at 11:11:32AM +0200, John Paul Adrian Glaubitz wrote:
> 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.

What performance impact do you see?  When using modern file systems
reducing the memory usage should eventually improve performance, although
this change will require additional file system changes to get there.
btrfs already has a series out, and I'm working on the XFS conversion
to remove the duplicate 64-bit inode information.

Either way 7.0 will reduce the inode size already, as the shrinking
mutex/rw_semaphore (and for the XFS inode semaphore) cuts a lot of space,
which even on 32-bit by far overshadows the increased size of i_ino.

I'm also not sure what personal notification you expect?  This has been
discussion in-and-out on linux-fsdevel.

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

[Christian Brauner]

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.