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

[Jeff Layton <jlayton@kernel.org>]

On Wed, 2026-03-04 at 12:03 -0500, Woody Suwalski wrote:
> Jeff Layton wrote:
> > This version squashes all of the format-string changes and the i_ino
> > type change into the same patch. This results in a giant 600+ line patch
> > at the end of the series, but it does remain bisectable.  Because the
> > patchset was reorganized (again) some of the R-b's and A-b's have been
> > dropped.
> > 
> > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > interested in testing this.
> > 
> >      https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > 
> > Original cover letter follows:
> > 
> > ----------------------8<-----------------------
> > 
> > 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.
> > 
> > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > 
> Jeff, would you be able to "guestimate" how much extra memory 
> requirement will it impose on 32-bit architectures? Probably nothing 
> critical, but good to know :-)
> 
> Thanks, Woody

It's hard to say since inode counts can vary widely depending on
workload, memory sizing and tuning:

If you have a particular machine in mind, you can look at the first
column in /proc/sys/fs/inode-state to get a current count of allocated
inodes on your system. Multiply that by 4 bytes and you get a best case
for the memory increase.

The real increase might be worse however -- this can have slabcache
alignment effects (and different filesystems have different inode
sizes). We may end up being able to mitigate this to some degree
however.

For instance, nfs (like many filesystems) carries a separate "fileid"
field in struct nfs_inode. That could now be dropped in favor of i_ino
since we always know it's a u64.

This set doesn't go that far because I want to keep this changeset as
small as possible, but there is a lot of that sort of low-hanging
cleanup that should be possible after this set goes in.
-- 
Jeff Layton <jlayton@kernel.org>