On Mon, Aug 04, 2008 at 10:37:20PM -0400, Oren Laadan wrote: > Louis Rilling wrote: >> On Fri, Aug 01, 2008 at 02:51:57PM -0400, Oren Laadan wrote: >>> Louis Rilling wrote: >>>> On Fri, Aug 01, 2008 at 10:15:26AM -0400, Oren Laadan wrote: >>> I actually wasn't thinking of streaming a series of incremental checkpoints >>> (from base and on) to implement migration... I simply didn't have a use-case >>> for that :) >> >> This could be useful however. Since incremental checkpoint is faster >> this could reduce down-time. > > Naturally incremental checkpoint reduces downtime; however since each checkpoint > is taken at a different time, they can be streamed -- transferred over the > network -- as they are taken. This gives more flexibility and can still, if > you wish, can easily be transformed to a single long stream. > > Actually, this is a good argument in favor of using multiple files: they are a > more flexible approach and can always be easily transformed to a single long > stream, while the reverse isn't so. Yes the reverse is as easy: rebuilding a full checkpoint of a given id #id consists simply in removing the records that are tagged as invalid as from checkpoints having ids <= #id. This is actually what restart should do :) >>>> The point is that you need previous data when building an incremental >>>> checkpoint, so you will read it at least. And since it was previously stored (in >>> The scheme that I described above and is implemented in Zap does not require >>> access to previous checkpoints when building a new incremental checkpoint. >>> Instead, you keep some data structure in the kernel that describes the pieces >>> that you need to carry with you (what pages were saved, and where; when a task >>> exits, the data describing its mm will be discarded, of course, and so on). >> >> This is because you probably decided that a mechanism in the kernel that saves >> storage space was not interesting if it does not improve speed. As a >> consequence you need to keep metadata in kernel memory in order to do >> incremental checkpoint. Maybe saving storage space without considering >> speed could equally be done from userspace with sort of checkpoint diff >> tools that would create an incremental checkpoint 2' from two full >> checkpoints 1 and 2. > > Good point. In fact, the meta data is not only kept in memory, but also saved > with each incremental checkpoint (well, its version at checkpoint time), so > that restart would know where to find older data. So it is already transfered > to user space; we may as well provide the option to keep it only in user space. That is userspace should give it back to the kernel before doing the next incremental checkpoint? Louis -- Dr Louis Rilling Kerlabs - IRISA Skype: louis.rilling Campus Universitaire de Beaulieu Phone: (+33|0) 2 99 84 71 52 Avenue du General Leclerc Fax: (+33|0) 2 99 84 71 71 35042 Rennes CEDEX - France http://www.kerlabs.com/ _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers