On 2019/7/1 9:52, Matthew Wilcox wrote: > 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. Hi, maybe sbitmap is not a good solution, max_inodes of tmpfs are controlled by mount options--nrinodes, which can be modified by remountfs(bigger or smaller), as the comment of function sbitmap_resize says: * Doesn't reallocate anything. It's up to the caller to ensure that the new * depth doesn't exceed the depth that the sb was initialized with. We can modify this to meet the growing requirements, there will still be questions as follows: 1. tmpfs is a ram filesystem, we need to allocate sbitmap memory for sbinfo->max_inodes(while this maybe huge) 2.If remountfs changes max_inode, we have to deal with it, while this may take a long time (bigger: we need to free the old sbitmap memory, allocate new memory, copy the old sbitmap to new sbitmap smaller: How do we deal with it?ie: we use sb->map[inode number/8] to find the sbitmap, we need to change the exist inode numbers?while this maybe used by userspace application.) > > . >
