[CRIU] [PATCH] stats/pid-reuse: put stats to image directory instead of cwd

[Pavel Emelyanov]

On 03/26/2018 02:33 PM, Pavel Tikhomirov wrote:
> 
> 
> On 03/26/2018 02:19 PM, Pavel Emelyanov wrote:
>> On 03/26/2018 02:02 PM, Cyrill Gorcunov wrote:
>>> On Mon, Mar 26, 2018 at 01:43:11PM +0300, Pavel Emelyanov wrote:
>>>> On 03/26/2018 12:16 PM, Pavel Tikhomirov wrote:
>>>>> On 03/26/2018 11:54 AM, Pavel Emelyanov wrote:
>>>>>> On 03/26/2018 11:12 AM, Pavel Tikhomirov wrote:
>>>>>>> Statistics for a special dump/pre-dump/restore action should be
>>>>>>> collected in the images directory of these action. We need these for
>>>>>>> pid-reuse detection as we need to read the stats of parent predump.
>>>>>>
>>>>>> What's wrong with checking pid-reuse form stats sitting in workdir?
>>>>>
>>>>> We can read previous dump statistics from workdir before
>>>>> cr_*dump_finish, I agree with that, it is easy.
>>>>>
>>>>> But Kirill says that "writing image outside of image directory is
>>>>
>>>> Stats file is not an image. We just use PB format for it and reuse existing
>>>> image-writing machinery.
>>>
>>> Stats file is context dependant and logically bound to images. At least
>>> keeping it inside image drectory gives you confidence the data written
>>> there belongs exactly to the images produced.
>>
>> So are logs, but we keep them in workdir anyway.
>>
>>> Because pid reuse uses
>>> data from stats to operate on memory engine it become not longer
>>> a random stat just to view, but mandatory data required for proper
>>> restore.
>>
>> I've missed that fast somehow. What's there in stats image the pid-reuse needs?
> 
> StatsEntry->dump->dump_uptime

Ah. I see. So, first of all, TIMING_whatever is not about time-stamps, it's about
"time taken to perform some action". Uptime doesn't fit into this and should not
have been added there. Next, as a dumping ground for various dump-related stuff
we traditionally use the inventory.img. And last, to detect pid-reuse you do not
want to have the uptime of the whole system in the iamges :) You want the time the
process has been alive for. This time is more valuable, as we currently have a bug 
with oracle restore -- "time alive" gets re-set to zero upon restore and oracle kills
all its kids. Had we this time and the ability to ... restore it somehow (time
namespace might be helpful) we'd solve it.

>>
>>> If you still prefer stats file to be on its own then I think we
>>> need use some other image to carry this information.
>>>
>>>>> architectural problem", actually I think these way too for at least two
>>>>> reasons:
>>>>>
>>>>> 1) When stats image is in images dir we can latter analize stats for
>>>>> each iteration if we want it. Now doing migration in VZ7 we have only
>>>>> stats of last dump in the end.
>>>>
>>>> The same problem's for log files (I hope nobody has moved them into images dir
>>>> so far), isn't it? Use separate workdir for each iteration.
>>>
>>> Exactly, same problem. And for vz7 the logs are kept in the image
>>> directory via vzctl option passed.
>>
>> Gents, by default criu keeps work dir and images together, some efforts should be
>> done to keep them separately. What option are you talking about?
> 
> Likely --log-file is used for logs and for images and workdir: 
> --images-dir and --work-dir.

Don't use --work-dir and work dir will be taken from --image-dir :)

>>
>>> Thus when a user comes to us with
>>> a problem we ask him to provide us logs from the image directory and
>>> if logs on self are not enough we can ask to pack images directory
>>> where the *complete* state of everything is present which we need
>>> to analyze a problem.
>>> .
>>>
>>
>