Memory dumps - Revision history

Xemul at 12:54, 13 July 2017

2017-07-13T12:54:34Z

Kir: /* Stacked images */ rephrasing

2016-08-31T06:10:41Z

Stacked images: rephrasing

Kir: /* Deduplication */ link to a separate article

2016-08-31T04:09:53Z

Deduplication: link to a separate article

Kir: /* Stacked images */ s/date/data/, some rewording

2016-08-30T20:50:30Z

Stacked images: s/date/data/, some rewording

Kir: add and populated 'see also'

2016-08-30T20:17:03Z

add and populated 'see also'

Kir: mv categories to the bottom, rm extra vertical whitespace

2016-08-30T20:09:52Z

mv categories to the bottom, rm extra vertical whitespace

Xemul: + plan for future

2015-02-24T12:53:12Z

+ plan for future

Xemul: + stack

2015-02-24T12:48:52Z

+ stack

Xemul at 12:42, 24 February 2015

2015-02-24T12:42:32Z

Xemul: +cat images

2015-02-24T12:34:47Z

+cat images

← Older revision		Revision as of 12:54, 13 July 2017
Line 71:		Line 71:
	[[Category:Memory]]		[[Category:Memory]]
	[[Category:Images]]		[[Category:Images]]
		+	[[Category:Editor help needed]]

@@ Line 36: / Line 36: @@
 == Stacked images ==
-When you do [[incremental dumps]] there appear the <code>parent</code> symlink and images with pages become dependant on each other.
+When [[incremental dumps]] are performed, for every iteration a <code>parent</code> symlink is created, and images become dependent on their respective parent(s).
-There appears the 3rd field in the pagemap, called <code>in_parent</code>. When set this boolean value means, that the respective data for the pagemap should be found in the parent images. While searching for data in parent the same algorithm is used -- first the pagemap is resolved, then the data is found in pages. For parent images, the data (either complete or partial) can also be found in ''its'' parent images.
+There appears the 3rd field in the pagemap, called <code>in_parent</code>. It is a boolean flag, when set, means the respective data for the given pagemap is available from a parent image. While searching for data in parent, the same algorithm is used -- first the pagemap is resolved, then the data is found in pages. For parent images, the data (either complete or partial) can also be found in ''its'' parent images.
-Respectively, the bottom image (with no parent link) should have no in_parent bits at all.
+Naturally, the bottom image (the one with no parent link) must have no <code>in_parent</code> bits set.
 === Example ===
-Let's take another example, consider we have pagemap from previous example with one in_parent bit:
+Consider we have a pagemap from the previous example with <code>in_parent</code> bit set for one entry:
 <pre>
@@ Line 51: / Line 51: @@
 </pre>
-In this case the pages image would be only 32k in size, since the first 4 pages should be found in the parent. Thus the parent pagemap image should container one ore more pagemaps that cover the <code>0x1000000 ... 0x1004000</code> area, for example like this
+In this case, the pages image would be only 32k in size, since the first 4 pages are to be found in the parent. Thus the parent pagemap image should container one or more pagemaps covering the <code>0x1000000 ... 0x1004000</code> area, for example, like this
 <pre>
@@ Line 58: / Line 58: @@
 </pre>
-This, in turn, would mean that first 2 pages from this range are in parent's pages image file and the last 2 should be looked up deeper -- in the grand-parent pagemaps.
+This, in turn, means that the first 2 pages from this range are available from the parent pages image file, and the last 2 should be looked up deeper, i.e. in the grand-parent pagemaps.
 == Deduplication ==

@@ Line 62: / Line 62: @@
 == Deduplication ==
-FIXME
+See [[Memory images deduplication]].
 == See also ==

@@ Line 38: / Line 38: @@
 When you do [[incremental dumps]] there appear the <code>parent</code> symlink and images with pages become dependant on each other.
-There appears the 3rd field in the pagemap, called <code>in_parent</code>. When set this boolean value means, that the respective data for the pagemap should be found in the parent images. While searching for data in parent the same algorithm is used -- first the pagemap is resolved, then the data is found in pages. For parent images the date (all, or part of it) can also be found in ''its'' parent images.
+There appears the 3rd field in the pagemap, called <code>in_parent</code>. When set this boolean value means, that the respective data for the pagemap should be found in the parent images. While searching for data in parent the same algorithm is used -- first the pagemap is resolved, then the data is found in pages. For parent images, the data (either complete or partial) can also be found in ''its'' parent images.
 Respectively, the bottom image (with no parent link) should have no in_parent bits at all.

@@ Line 67: / Line 67: @@
 === Deduplication on restore ===
 [[Category:Memory]]
 [[Category:Images]]

← Older revision		Revision as of 12:53, 24 February 2015
Line 64:		Line 64:
	[[Category:Memory]]		[[Category:Memory]]
	[[Category:Images]]		[[Category:Images]]
		+
		+	== Deduplication ==
		+
		+	FIXME
		+
		+	=== Auto-deduplication ===
		+
		+	=== Deduplication on restore ===

@@ Line 1: / Line 1: @@
 This page describes the way memory is stored in the image files.
 [[Category:Empty articles]]
 [[Category:Memory]]
 [[Category:Images]]

← Older revision		Revision as of 12:34, 24 February 2015
Line 3:		Line 3:
	[[Category:Empty articles]]		[[Category:Empty articles]]
	[[Category:Memory]]		[[Category:Memory]]
		+	[[Category:Images]]