Difference between revisions of "Incremental dumps"

From CRIU
Jump to navigation Jump to search
(→‎Restore: fix English, kill double vertical space)
(reformat, fix English, typos)
Line 38: Line 38:
 
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.
 
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.
  
; Deduplication action
+
=== Deduplication action ===
: The <code>criu dedup</code> command would open the image directory and punch holes in the ''parent'' images in needed places
+
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
+
=== Automatic deduplication while dumping ===
: The <code>--auto-dedup</code> option would cause every write to images with process' pages to go an punch holes in respective parent images.
+
The <code>--auto-dedup</code> option would cause every write to images with process' pages to go an punch holes in respective parent images.
  
The latter option appies to both <code>dump</code> and <code>page-server</code> actions and thus is extremely useful in [[disk-less migration]] scenario.
+
This option applies to both <code>dump</code> and <code>page-server</code> actions and thus is extremely useful in [[disk-less migration]] scenario.
  
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
 
[[Category:Memory]]
 
[[Category:Memory]]

Revision as of 23:41, 29 August 2016

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

# 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

# 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

# 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

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

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.

Deduplication action

The criu dedup command opens the image directory and punch holes in the parent images where child images would replace them.

Automatic deduplication while dumping

The --auto-dedup option would cause every write to images with process' pages to go an punch holes in respective parent images.

This option applies to both dump and page-server actions and thus is extremely useful in disk-less migration scenario.