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 21: |
Line 23: |
| | | |
| # mkdir <path-to-images>/N/ | | # mkdir <path-to-images>/N/ |
− | # criu dump --tree <pid> --images-dir <path-to-images>/N/ --prev-images-dir ../N-1/ | + | # criu dump --tree <pid> --images-dir <path-to-images>/N/ --track-mem --prev-images-dir ../N-1/ |
| | | |
| * No <code>--leave-running</code> option will make tasks be killed after dump; | | * No <code>--leave-running</code> option will make tasks be killed after dump; |
Line 32: |
Line 34: |
| # criu restore --images-dir <path-to-images>/ANY/ | | # 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.}} |
− | {{Note|After each (but the last) dump tasks continue running and thus can modify filesystem. CRIU doesn't snapshot filesystem and assumes, that proper filesystem state for restore is provided by user}} | |
| | | |
| == 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>crui dedup</code> command would open the image directory and punch holes in the ''parent'' images in needed places
| |
| | | |
− | ; 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.
| |
| | | |
− | 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.
| + | * [[Live migration]] |
| + | * [[Disk-less migration]] |
| + | * [[Iterative migration]] |
| + | * [[Memory images deduplication]] |
| + | * [[Page server]] |
| | | |
| [[Category:HOWTO]] | | [[Category:HOWTO]] |
| + | [[Category:Memory]] |