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. _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
