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:
> > 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 <[email protected]>