Re: [libvirt] [PATCH v8 03/21] backup: Introduce virDomainCheckpoint APIs

On 4/24/19 8:26 AM, Peter Krempa wrote: I can add documentation, but the short answer is that there are two ways to implement differential backups: 1. One active bitmap for every point in time that you might ever need a differential backup from; if you have 20 checkpoints, then you have 20 active bitmaps, and each guest write has to potentially modify all 20 bitmaps, but backups can directly use the desired bitmap and nothing else for that particular backup: Time: T1 T2 T3 T4 present Bitmap1: -------------------------------- Bitmap2: -------------------------- Bitmap3: ------------------- Bitmap4: ------------ 2. One disabled bitmap for every delta between two consecutive points in time, plus one active bitmap since the most recent point in time; if you have 20 checkpoints, then you have 19 disabled bitmap and 1 active 1, where each guest write only has to modify 1 bitmap, but backups have to construct a temporary bitmap that contains the union of all bitmaps that span the time in question: Time: T1 T2 T3 T4 present Bitmap1: ------ Bitmap2: ------- Bitmap3: ------- Bitmap4: ------------ Given that guest writes are more frequent than backup operations, and that performing the creation of a temporary bitmap to merge together other bitmaps at the start of a bitmap is not all that onerous, the code goes with approach 2. And, since there is always 1 active bitmap while the rest are disabled, it lends itself well to the notion of a current checkpoint (one that is tracking active guest writes). Right now, it needs to be an error (until we actually design how the two should play together nicely, the most conservative approach is to state that reverting a domain with checkpoints risks enough confusion to be forbidden in the initial implementation, even if we lift that restriction later when we iron out how it should work). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org