Re: [PATCH 02/61] vfs: change i_ino from unsigned long to u64

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2026-02-26 at 11:16 -0500, Mathieu Desnoyers wrote:
> On 2026-02-26 10:55, Jeff Layton wrote:
> > Change the type of i_ino in struct inode from unsigned long to u64.
> > 
> > On 64-bit architectures, unsigned long is already 64 bits, so this is
> > effectively a type alias change with no runtime impact. On 32-bit
> > architectures, this widens i_ino from 32 to 64 bits, allowing
> > filesystems like NFS, CIFS, XFS, Ceph, and FUSE to store their native
> > 64-bit inode numbers without folding/hashing.
> > 
> > The VFS already handles 64-bit inode numbers in kstat.ino (u64) and
> > statx.stx_ino (__u64). The existing overflow checks in cp_new_stat(),
> > cp_old_stat(), and cp_compat_stat() handle narrowing to 32-bit st_ino
> > with -EOVERFLOW, so userspace ABI is preserved.
> > 
> > struct inode will grow by 4 bytes on 32-bit architectures.
> 
> Changing this type first without changing its associated format strings
> breaks git bisect.
> 
> One alternative would be to introduce something like the PRIu64 macro
> but for printing inode values. This would allow gradually introducing
> the change without breaking the world as you do so.
> 
> 

True, but it makes all of the format strings even harder to read. After
the conversion, we could go back and eliminate the macro though and it
would keep things more bisectable. I'm not sure what to do about
tracepoints though. I guess we could declare a new typedef and change
its definition when i_ino's type changes?

I'll let others chime in first, but I'm open to going back and doing it
that way if we don't want to live with the compiler warnings during a
bisect.

-- 
Jeff Layton <jlayton@kernel.org>