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

Christian Brauner
2026-02-27T10:07:10Z

On Thu, Feb 26, 2026 at 10:55:02AM -0500, 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.
>
> [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/

I'm working under the assumption that we have crossed the threshold and
people send patches they did completely themselves and also patches that
were done with the help of or almost completely by a tool. You have to
defend it one way or the other.

Frankly, as long as you understand what you're doing in general well and
I know that you are a trusted and thorough developer/maintainer I could
not care less if you tell me whether or not you did this all on your
own or with the help of some tool. In my experience, laziness grows with
experience but so does the amount of ideas.

So attribute it to yourself or attribute it partially to the tool. I
personally don't care.