[Devel] [Q] migrating inotify assigned on ploop device

[Nikita Spiridonov]

On Tue, 2016-01-12 at 15:33 +0300, Cyrill Gorcunov wrote:
> On Tue, Jan 12, 2016 at 03:12:15PM +0400, Nikita Spiridonov wrote:
> > On Tue, 2016-01-12 at 13:49 +0300, Cyrill Gorcunov wrote:
> > > On Tue, Jan 12, 2016 at 01:30:28PM +0300, Pavel Emelyanov wrote:
> > > > 
> > > > Plz read my last chapter:
> > > > 
> > > > > Should we work on images copy instead? Which gonna be horrible design :)
> > > > > 
> > > > >>
> > > > >> On restore we need to patch criu to spawn crit with recode action and
> > > > >> necessary recode rules. CRIT then would read data from images and write
> > > > >> them back to criu via pipe.
> > > > 
> > > > crit writes modified data into pipe that goes to criu instead of opened
> > > > image fd.
> > > 
> > > Managed to miss it, thanks!
> > 
> > So, finally, we must patch criu and enable that recoding passing some
> > command line option from libvzctl to fix issue?
> 
> I think so. We need to invent some kind of such protocol to be suitable
> for use with p.haul and libvzctl, the criu itself should not be changed
> I think. For criu it like some extrrnal modifications.
> 
> As to performance: we don't have to patch "all" images (really huge
> data sits in "page" images) but only those which might be affected by
> device name mapping. In particular:
> 
>  - reg-files
>  - inotify
>  - mount points
> 
> and maybe someone else. Pavel said he tried "recode" testing in CRIT
> and it works pretty fast. Not sure though which exactly tests were running.
> 
> 	Cyrill

Lets try to fix bug using workaround in libvzctl and criu hooks. Images
recoding/patching too hard to implement for now; we can return to it
later.