[CRIU] [PATCH] link_remap: do not create excessive links for a single file

[Pavel Emelyanov]

On 07/27/2016 07:33 PM, Stanislav Kinsburskiy wrote:
> 
> 
> 14.07.2016 12:56, Pavel Emelyanov пишет:
>> On 07/13/2016 05:29 PM, Stanislav Kinsburskiy wrote:
>>>
>>> 13.07.2016 16:30, Pavel Emelyanov пишет:
>>>> On 07/13/2016 04:10 PM, Stanislav Kinsburskiy wrote:
>>>>> 13.07.2016 14:48, Pavel Emelyanov пишет:
>>>>>> On 06/30/2016 08:11 PM, Stanislav Kinsburskiy wrote:
>>>>>>> Currently criu always creates link for each file, considered as "silly-renamed".
>>>>>>> Even in those cases, when file is opened multiple times, it creates one new
>>>>>>> link for each occurrence.
>>>>>>> On restore only one link file is used for all the file descriptors, sharing
>>>>>>> this path. And only this link is removed.
>>>>>> Would you cook a zdtm test showing it?
>>>>> Sorry, I don't understand. Showing what exactly?
>>>>> I caught by using zdtm tests. Test "static/unlink_mmap00" should expose it.
>>>>> Two links created, only one used and unlinked. Another one stays on the
>>>>> disk.
>>>> And test passes :) Then modify it (or it's cleanup hook) to catch this error.
>>> Checking for no "link_remap*" files left suits your purpose?
>> Yup :) IIRC we already have some test hook doing checks for ghost/remaps files
>> hanging around.
>>
> 
> Looks like this patch is obsolete with current criu dev in terms of 
> abandoned link files left after restore.
> Now criu uses all of them as expected (the dumped one is used for 
> restore and then unlinked).
> Thus this patch is nothing more that optimization (create only one link 
> instead of many).
> Are you still willing to take it in this circumstances?

Will it let us use less system calls to dump anything? If yes, then I will, but
it looks like Evgeny Batalov's patch with criu gc will interfere with this one.

-- Pavel