Dave Chinner writes: > On Sun, Jan 05, 2020 at 12:06:05PM +0000, Chris Down wrote: > > The default is still set to inode32 for backwards compatibility, but > > system administrators can opt in to the new 64-bit inode numbers by > > either: > > > > 1. Passing inode64 on the command line when mounting, or > > 2. Configuring the kernel with CONFIG_TMPFS_INODE64=y > > > > The inode64 and inode32 names are used based on existing precedent from > > XFS. > > Please don't copy this misfeature of XFS. > > The inode32/inode64 XFS options were a horrible hack made more than > 20 years ago when NFSv2 was still in use and 64 bit inodes could > not be used for NFSv2 exports. It was then continued to be used > because 32bit NFSv3 clients were unable to handle 64 bit inodes. > > 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. Hi, It's unfortunately not true that everything handles this correctly. 32-bit binaries for games on Steam that use stat() without the 64 is so prevalent that I got tired of adding the LD_PRELOAD wrapper script and just patched out the EOVERFLOW return from glibc instead. (They obviously don't care about the inode value at all, and I don't use any other 32-bit binaries that do). This is probably a class of binaries you don't care very much about, and not very likely to be installed on a tmpfs that has wrapped around, but I thought it was worth mentioning that they do exist anyway. -- Mikael Magnusson
