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?
Yes, it happens in practice. we use a script to test it, after 10 days, this problem will happen:
while the script are as follows:
while(1) {
create a file
dlopen it
...
remove it
}
>> 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.
I will study sbitmap data structure
> .
>
