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

[Pavel Emelyanov]

On 04/13/2016 04:01 PM, Stanislav Kinsburskiy wrote:
> 
> 
> 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?

We have path-remaps for the cases when regular open()-ing of a file
should be somehow tweaked. I guess this is the case for yet another
remap type (right now we have 3 -- ghost, link remap and dead pid).

-- Pavel