Incremental dumps - Revision history

Kir: /* See also */ add Memory images deduplication link

2016-08-31T04:21:04Z

See also: add Memory images deduplication link

2016-08-31T04:20:33Z

Data deduplication: link to a separate article

2016-08-30T20:14:58Z

add and populated 'see also'

2016-08-30T01:05:50Z

added a big fat FIXME

2016-08-29T23:41:17Z

reformat, fix English, typos

2016-08-29T23:38:27Z

Restore: fix English, kill double vertical space

2016-08-29T23:35:16Z

It's either "sped up" or "speeded up". The first form is used 3x more frequent

2016-06-24T12:30:43Z

typo fixed

2016-06-24T12:30:17Z

typo fixed

2015-01-28T17:58:37Z

@@ Line 45: / Line 45: @@
 * [[Disk-less migration]]
 * [[Iterative migration]]
 * [[Page server]]
 [[Category:HOWTO]]
 [[Category:Memory]]

@@ Line 38: / Line 38: @@
 == 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]].
 == See also ==

@@ Line 47: / Line 47: @@
 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:Memory]]

← Older revision		Revision as of 01:05, 30 August 2016
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 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.
-; 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:Memory]]

@@ Line 32: / Line 32: @@
   # criu restore --images-dir <path-to-images>/ANY/
+{{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 ==

← Older revision		Revision as of 23:35, 29 August 2016
Line 1:		Line 1:
−	If you're doing several dumps in a row, the 2nd and subsequent dumps can be ~~speed~~ 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:

	== Create the first dump ==		== Create the first dump ==

← Older revision		Revision as of 12:30, 24 June 2016
Line 1:		Line 1:
−	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 speed up. Here's how:

	== Create the first dump ==		== Create the first dump ==