Oren Laadan <orenl@xxxxxxxxxxxxxxx> writes: > Alexey Dobriyan wrote: >>> Again, so to checkpoint one task in the topmost pid-ns you need to >>> checkpoint (if at all possible) the entire system ?! >> >> One more argument to not allow "leaks" and checkpoint whole container, >> no ifs, buts and woulditbenices. >> >> Just to clarify, C/R with "leak" is for example when process has separate >> pidns, but shares, for example, netns with other process not involved in >> checkpoint. >> >> If you allow this, you lose one important property of checkpoint part, >> namely, almost everything is frozen. Losing this property means suddenly >> much more stuff is alive during dump and you has to account to more stuff >> when checkpointing. You effectively checkpointing on live data structures >> and there is no guarantee you'll get it right. > > Alexey, we're entirely on par about this: everyone agrees that if you > want the maximal guarantee (if one exists) you must checkpoint entire > container and have no leaks. > > The point I'm stressing is that there are other use cases, and other > users, that can do great things even without full container. And my > goal is to provide them this capability. As it seems that Alexey's goal is more or less a subset of yours, would it make sense in the near term to concentrate on getting an implementation upstream that satisfies that subset (i.e. checkpoint on a container basis only)? And then support for checkpointing arbitrary processes could be added later, if it proves feasible? _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
