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

[Mathieu Desnoyers]

On 2026-02-26 11:45, Jeff Layton wrote:
> On Thu, 2026-02-26 at 11:40 -0500, Mathieu Desnoyers wrote:
> > 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.
>
> My worry here is that ino_t is a UAPI type, and I don't think we can
> change it there. I think we'll need a new (kernel-internal) typedef
> just for this.

If ino_t is UAPI then it cannot be changed, but you can introduce a new
kino_t or whatever naming is appropriate.

Thanks,

Mathieu

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