On Mon, Jul 01, 2019 at 09:48:03AM +0800, zhengbin (A) wrote: > > 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? > > Yes, if two files share the same inode number, when application uses dlopen to get > > file handle, there will be problems. That wasn't what I meant. Does it happen in practice? Have you observed it, or are you just worrying about a potential problem? > 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. > > I'd be more convinced by a patch to use > > the sbitmap data structure than a blind conversion to use atomic64_t. You ignored this sentence.
