{{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.