Difference between revisions of "Incremental dumps"

From CRIU
Jump to navigation Jump to search
(reformat, fix English, typos)
m (→‎See also: add Memory images deduplication link)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
{{FIXME|describe why incr. dumps are needed, and when to use pre-dump ([[iterative migration]]) instead of incr. dumps.}}
 +
 
If you're doing several dumps in a row, the 2nd and subsequent dumps can be sped up. Here's how:
 
If you're doing several dumps in a row, the 2nd and subsequent dumps can be sped up. Here's how:
  
Line 36: Line 38:
 
== Data deduplication ==
 
== Data deduplication ==
  
−
After creation of such stack of images some data would get duplication in dumps. If you don't want to keep duplicates there's an ability to punch duplicate data from non-top images. There are two options for this.
+
See [[memory images deduplication]].
−
 
 
−
=== Deduplication action ===
 
−
The <code>criu dedup</code> command opens the image directory and punch holes in the ''parent'' images where ''child'' images would replace them.
 
  
−
=== Automatic deduplication while dumping ===
+
== See also ==
−
The <code>--auto-dedup</code> option would cause every write to images with process' pages to go an punch holes in respective parent images.
 
  
−
This option applies to both <code>dump</code> and <code>page-server</code> actions and thus is extremely useful in [[disk-less migration]] scenario.
+
* [[Live migration]]
 +
* [[Disk-less migration]]
 +
* [[Iterative migration]]
 +
* [[Memory images deduplication]]
 +
* [[Page server]]
  
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
 
[[Category:Memory]]
 
[[Category:Memory]]

Latest revision as of 04:21, 31 August 2016

Tools-spanner-hammer.svg FIXME: describe why incr. dumps are needed, and when to use pre-dump (iterative migration) instead of incr. dumps.

If you're doing several dumps in a row, the 2nd and subsequent dumps can be sped up. Here's how:

Create the first dump[edit]

# mkdir -p <path-to-images>/1/
# criu dump --tree <pid> --images-dir <path-to-images>/1/ --leave-running --track-mem
  • Images are put into the 1/ sub-directory, since we're about to create the 2nd (and more) incremental dumps and it's handy to store them in this way;
  • The --leave-running option is used to make criu not kill the tasks after dump, but let them run further;
  • The --track-mem option makes criu ask kernel to monitor memory changes to optimize the subsequent dump.

Create the second dump[edit]

# mkdir <path-to-images>/2/
# criu dump --tree <pid> --images-dir <path-to-images>/2/ --leave-running --track-mem --prev-images-dir ../1/
  • Note, that the --prev-images-dir path is relative to the --images-dir one;
  • Similarly the 3rd and all the other dumps can be created.

Create the last dump[edit]

# mkdir <path-to-images>/N/
# criu dump --tree <pid> --images-dir <path-to-images>/N/ --track-mem --prev-images-dir ../N-1/
  • No --leave-running option will make tasks be killed after dump;
  • No need in memory tracking option.

Restore[edit]

Now you can restore the processes from whatever images you want 

# criu restore --images-dir <path-to-images>/ANY/
Note.svg Note: After each (but the last) dump tasks continue running and thus can modify filesystem. CRIU does not snapshot filesystem and assumes, that proper filesystem state for restore is provided by a user.

Data deduplication[edit]

See memory images deduplication.

See also[edit]

Retrieved from "https://criu.org/index.php?title=Incremental_dumps&oldid=3111"