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

[Mathieu Desnoyers]

On 2026-02-26 11:35, Jeff Layton wrote:
> 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?

For tracepoints there are two things: a TP_printk format string (which
would be handled by a new pretty printing macro similar to PRIu64), and
the type used within TP_STRUCT__entry. I don't see why you'd need to
change from ino_t to u64 there. The conversion will happen when you flip
the ino_t typedef from unsigned long to u64.

> 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.

On 32-bit archs, I suspect it will do more than emit compiler warnings.
Trying to boot a kernel in the middle of the series is likely to lead to
interesting inode value printout results.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com