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

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

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