Re: [PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64

On Fri, 2026-02-27 at 10:30 +0100, Christian König wrote:

On 2/26/26 16:55, Jeff Layton wrote:

quoted

Christian said [1] to "just do it" when I proposed this, so here we are!

For historical reasons, the inode->i_ino field is an unsigned long,
which means that it's 32 bits on 32 bit architectures. This has caused a
number of filesystems to implement hacks to hash a 64-bit identifier
into a 32-bit field, and deprives us of a universal identifier field for
an inode.

This patchset changes the inode->i_ino field from an unsigned long to a
u64. This shouldn't make any material difference on 64-bit hosts, but
32-bit hosts will see struct inode grow by at least 4 bytes. This could
have effects on slabcache sizes and field alignment.

The bulk of the changes are to format strings and tracepoints, since the
kernel itself doesn't care that much about the i_ino field. The first
patch changes some vfs function arguments, so check that one out
carefully.

With this change, we may be able to shrink some inode structures. For
instance, struct nfs_inode has a fileid field that holds the 64-bit
inode number. With this set of changes, that field could be eliminated.
I'd rather leave that sort of cleanups for later just to keep this
simple.

Much of this set was generated by LLM, but I attributed it to myself
since I consider this to be in the "menial tasks" category of LLM usage.

Sounds reasonable to me, should get_next_ino() also be changed to return an 64bit ino?

I'm not opposed to doing that, but I'd probably leave that for a
follow-on cleanup. Just doing the i_ino conversion is already making
for a huge patchset.
-- 
Jeff Layton [off-list ref]