[CRIU] [PATCH RFC 0/2] Mount point hash

[Stanislav Kinsburskiy]

24.03.2016 15:19, Pavel Emelyanov пишет:
> On 03/23/2016 04:31 PM, Stanislav Kinsburskiy wrote:
>>
>> 23.03.2016 13:53, Pavel Emelyanov пишет:
>>> On 03/23/2016 02:16 PM, Stanislav Kinsburskiy wrote:
>>>> 23.03.2016 12:14, Pavel Emelyanov пишет:
>>>>> On 03/17/2016 03:53 PM, Stanislav Kinsburskiy wrote:
>>>>>> This series introduces hash for mount points.
>>>>>> The major reason for it is upcomming NFS migration, which is expected to
>>>>>> heavily search over mount points by mnt_id (to be able to get file system ID
>>>>>> instead of statfs() call, for instance).
>>>>>> The idea is trivial and doesn't require an explicit explanation.
>>>>>> However, there will be two sets of mount points is this series is merged: hash
>>>>>> and list.
>>>>>> List looks redundant and less efficient. Traversing hash table for all the
>>>>>> mounts has the same complexity as over the list: O(n).
>>>>>> But replacing the list with hash will require a lot or code refactoring, and
>>>>>> I'm not sure, does it worth it.
>>>>> The mnt_id, which you plan to use to lookup fstype for file descriptors,
>>>>> was introduced later than 3.11, thus this patch won't make any use for
>>>>> this kernel.
>>>> Sorry, but I don't understand what you are trying to say by this comment.
>>>> Could you please elaborate?
>>> You introduce this set to make '[PATCH RFC 2/2] mount: "get fs type by mount
>>> id" helper introduced' work faster, don't you?
>>>
>>> My point is that the mnt_id, using which you search for mount-info, is not
>>> available for files on kernels prior to ... 3.15 and is thus not extremely
>>> useful. Probably.
>> Probably. But, frankly, I still don't really get the point (the only
>> explanation, is that I wasn't clear enough in series description).
>>
>> This is "RFC" of a precursor patch set for NFS migration support.
>> NFS dump requires to get rid of statfs() calls, because network is
>> locked already, while NFS tries to access server on this system call.
>> There no simple way, how kernel can be fixed in this place to suppress
>> network accesses.
>>
>> Below are assumptions, allowing to get rid of statfs() calls in CRIU (at
>> least for NFS, but, actually, for almost all file systems, except, maybe
>> overlayfs and autfs):
>> 1) Statfs() is used only to get file system type.
>> 2) File system type is a part of userspace API and is a pair to file
>> system name. IOW they are constants.
>> 3) It makes sense to place file system type as constant declaration on
>> fstype structure.
>> 4) Instead of calling statfs(), CRIU can search for mountinfo object by
>> mnt_id
> Here's where things break. Criu doesn't always have this value.
>

Does it mean, that adding check for "mnt_id != -1" and in this case:

1) Do not hash mount
2) Return -ENOENT on search

will be sufficient?

>> and obtain fail system type from corresponding fstype (if available).
>> 5) Search for mountinfo is done currently by traversing the list. This
>> is slow. Hash is aimed to solve the problem of this slow search.
>>
>> Summary: hash allows to make search for mountinfo->fstype->fs_magic
>> fast. This is important for CRIU to reduce time costs for upcomming NFS
>> dump.
>>
>> BTW, some kernel patching will be required anyway to support NFS dump.
>> IOW, NFS migration won't be supported on 3.11 anyway.
>>
>>> -- Pavel
>> .
>>