Re: [LSF/MM/BPF TOPIC] Should we make inode->i_ino a u64?
John Paul Adrian Glaubitz <[email protected]>
| Newsgroups | gmane.linux.ports.sh.devel,gmane.linux.file-systems,gmane.linux.ports.m68k |
|---|---|
| Message-ID | <1b340c4e635dcab3bed8c52d6381b4c341c0741a.camel@physik.fu-berlin.de> |
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