On 2019/6/29 22:21, Matthew Wilcox wrote: > On Sat, Jun 29, 2019 at 08:28:13PM +0800, zhengbin wrote: >> tmpfs use get_next_ino to get inode number, if last_ino wraps, >> there will be files share the same inode number. Change last_ino >> type to unsigned long. > Is this a serious problem? I'd be more convinced by a patch to use > the sbitmap data structure than a blind conversion to use atomic64_t. Yes, if two files share the same inode number, when application uses dlopen to get file handle, there will be problems. Maybe we could use iunique to try to get a unique i_ino value(when we allocate new inode, we need to add it to the hashtable), the questions are: 1. inode creation will be slow down, as the comment of function iunique says: * BUGS: * With a large number of inodes live on the file system this function * currently becomes quite slow. 2. we need to convert all callers of get_next_ino to use iunique (tmpfs, autofs, configfs...), moreover, the more callers are converted, the function of iunique will be more slower. Looking forward to your reply, thanks. > . >
