On Thu, 21 Nov 2019, zhengbin (A) wrote: > On 2019/11/21 12:52, Hugh Dickins wrote: > > Just a rushed FYI without looking at your patch or comments. > > > > Internally (in Google) we do rely on good tmpfs inode numbers more > > than on those of other get_next_ino() filesystems, and carry a patch > > to mm/shmem.c for it to use 64-bit inode numbers (and separate inode > > number space for each superblock) - essentially, > > > > ino = sbinfo->next_ino++; > > /* Avoid 0 in the low 32 bits: might appear deleted */ > > if (unlikely((unsigned int)ino == 0)) > > ino = sbinfo->next_ino++; > > > > Which I think would be faster, and need less memory, than IDA. > > But whether that is of general interest, or of interest to you, > > depends upon how prevalent 32-bit executables built without > > __FILE_OFFSET_BITS=64 still are these days. > > So how google think about this? inode number > 32-bit, but 32-bit executables > cat not handle this? Google is free to limit what executables are run on its machines, and how they are built, so little problem here. A general-purpose 32-bit Linux distribution does not have that freedom, does not want to limit what the user runs. But I thought that by now they (and all serious users of 32-bit systems) were building their own executables with _FILE_OFFSET_BITS=64 (I was too generous with the underscores yesterday); and I thought that defined __USE_FILE_OFFSET64, and that typedef'd ino_t to be __ino64_t. And the 32-bit kernel would have __ARCH_WANT_STAT64, which delivers st_ino as unsigned long long. So I thought that a modern, professional 32-bit executable would be dealing in 64-bit inode numbers anyway. But I am not a system builder, so perhaps I'm being naive. And of course some users may have to support some old userspace, or apps that assign inode numbers to "int" or "long" or whatever. I have no insight into the extent of that problem. Hugh
