Is the mount option needed for backwards compat? Any system that creates that many files, should be large file aware, hopefully? Maybe it comes down to many files being created (and deleted) during the lifetime of the tmpfs mount, i.e usage time, not size, without any counter reset.<p>A system that uses "our identifier space is approximately infinite" can be fragile in a surprising way. A system that uses "our identifier space is proportional to the physical size of the medium" is more humanly predictable in its limitations.
Similarly, XFS has the inode32/64 mount options. Since kernel 3.7 inode64 is the default: <a href="https://man7.org/linux/man-pages//man5/xfs.5.html" rel="nofollow">https://man7.org/linux/man-pages//man5/xfs.5.html</a>
I enabled `pam_namespace` for per-user `/tmp` and `/var/tmp` on the systems I administer with those filesystems being tmpfs and xfs respectively. We get odd problems weekly where one or other user can't write to `/tmp` (but nsenter fails to reproduce it) but have never had issues with the `/var/tmp`. We came from Solaris where tmpfs was standard for `/tmp` and it surprised me to find that it seems to be an unusual choice on Linux. Are there reasons it isn't widely deployed on Linux? I can't think why inode reuse could cause the problems I experience but if I can enable this inode64 option, I'll give it a try.
I've not come across FS_IOC_GETVERSION before. Should the many user-mode applications that rely on st_dev, st_ino being enough to identify an inode also be calling this ioctl? Or is it something you only need to worry about in limited circumstances?