Dave Chinner writes:
It took 15 years for us to be able to essentially deprecate inode32 (inode64 is the default behaviour), and we were very happy to get that albatross off our necks. In reality, almost everything out there in the world handles 64 bit inodes correctly including 32 bit machines and 32bit binaries on 64 bit machines. And, IMNSHO, there no excuse these days for 32 bit binaries that don't using the *64() syscall variants directly and hence support 64 bit inodes correctlyi out of the box on all platforms. I don't think we should be repeating past mistakes by trying to cater for broken 32 bit applications on 64 bit machines in this day and age.
I'm very glad to hear that. I strongly support moving to 64-bit inums in all cases if there is precedent that it's not a compatibility issue, but from the comments on my original[0] patch (especially that they strayed from the original patches' change to use ino_t directly into slab reuse), I'd been given the impression that it was known to be one.
From my perspective I have no evidence that inode32 is needed other than the comment from Jeff above get_next_ino. If that turns out not to be a problem, I am more than happy to just wholesale migrate 64-bit inodes per-sb in tmpfs.
0: https://lore.kernel.org/patchwork/patch/1170963/
