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

[Stanislav Kinsburskiy]

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 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