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

[Stanislav Kinsburskiy]

13.04.2016 14:57, Pavel Emelyanov пишет:
> On 04/13/2016 01:34 PM, Stanislav Kinsburskiy wrote:
>
>>>> 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?
> No, you're right. The device is already not known at this point. But on the
> other hand, you can detect that the file is NFS based (and thus will require
> proxy on restore) during dump.

Agreed. But then rises a question, what is the best way to carry this 
information to the restore side.
It has to be placed int reg_file_entry (or somewaht similar) to 
illuminate any additional search in open_path(). Some kind of 
"delayed_file" bit.
Is it suitable?