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

[Stanislav Kinsburskiy]

29.07.2016 11:05, 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.

It will.
I can rebase this patch, if you satisfied with the one checking for link 
remap files in zdtm.py.

> -- Pavel
>