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

[Stanislav Kinsburskiy]

24.03.2016 19:07, Pavel Emelyanov пишет:
> On 03/24/2016 05:52 PM, Stanislav Kinsburskiy wrote:
>>
>> 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?
> It will look strange. I'd better hash stuff based on super block devices and
> report fstype by device.

The reason for using mnt_id as a key is that hash search have to be 
performed in open_path() before actual open_cb() call. If the search 
results indicates, that file belongs to NFS, it (file) have to be 
"emulated" (created) and then used for open.
As far as I see, s_dev tag is not available in this function.
Or do I miss something?