Changes

Jump to: navigation, search

Memory dumps

1,308 bytes added, 12:48, 24 February 2015
+ stack
In this case the pages should have 12 pages in it, i.e. be 48K in size. Then the first 4 pages (16k, the first pagemap entry) would be read from image and put at address 0x1000000 thus occupying space up to the <code>0x1000000 + 4 * 4096 = 0x1004000</code> address. The last 8 pages (32k, the 2nd pagemap entry) would be read and put at the 0xCF000000 address.
 
== Stacked images ==
 
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.
 
Respectively, the bottom image (with no parent link) should have no in_parent bits at all.
 
=== Example ===
 
Let's take another example, consider we have pagemap from previous example with one in_parent bit:
 
<pre>
{ 0x1000000, 4, in_parent }
{ 0xCF000000, 8 }
</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
 
<pre>
{ 0x1000000, 2 }
{ 0x1002000, 2, in_parent }
</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.
 
[[Category:Empty articles]]
[[Category:Memory]]
[[Category:Images]]

Navigation menu