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

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

-- Pavel