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

[Andrew Vagin]

On Mon, Mar 26, 2018 at 02:48:51PM +0300, Pavel Emelyanov wrote:
> 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.

It is a good idea.

> 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.

In this context, if a process died and then it was restored, this should be
detected as pid-reuse.

> 
> >>
> >>> 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.
> >>> .
> >>>
> >>
> > 
>