Hugh Dickins: > 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, > > =09ino =3D sbinfo->next_ino++; > =09/* Avoid 0 in the low 32 bits: might appear deleted */ > =09if (unlikely((unsigned int)ino =3D=3D 0)) > =09=09ino =3D sbinfo->next_ino++; I agree with that "per superblock inum space", but I don't see your point. How can you manage it fully? I mean how can you decide whether the new inum is in use or not? For example, - you create a file which is assigned inum#10. - you or other people create and unlink over and over on the same tmpfs. - then sbinfo->next_ino will become zero, skipped, ok. - and then it will be 10. I don't think you want to share the same inum by two inodes. Moreover, SysV SHM uses tmpfs and shmget(2) overwrite inum internally. It will be another seed of a similar problem. J. R. Okajima
