Re: [Qemu-devel] [Questions] Several questions about incremental backup

[Rudy Zhang <rudyflyzhang@gmail.com>]

On 16/1/26 上午3:19, John Snow wrote:
> 
> 
> On 01/25/2016 02:35 AM, Rudy Zhang wrote:
>> I am reading and testing the function: incremental backup in qemu-2.5.
>> But I have serveral questions about it.
>> 1. If I want to start image backup, at first I need to start full mode backup
>>    and then, add a bitmap to trace io, next start incremental backup via the
>>    bitmap before we added. But when the first incremental backup over, it will
>>    abdicate the bitmap. How can I start the second incremental backup without
>>    the bitmap to trace io? I don't know why abdicate the bitmap.
>>    Is it only an incremental backup?
> 
> Check out https://github.com/qemu/qemu/blob/master/docs/bitmaps.md for
> some examples of workflow, hopefully this is useful.
> 
> When you create a new bitmap object, it's useful to sync it to a full
> backup of some kind so that it's useful, you can do this several ways.
> Either QMP commands while the VM is paused, or QMP transactions when the
> VM is running. See /docs/bitmaps.md for more information.
> 
> When you issue a backup command using an incremental bitmap object, QEMU
> actually creates a new bitmap to replace the one you are using right away.
> 
> Before a backup: [bitmap0]
> During a backup: [bitmap0 <-- "successor"]
> 
> The bitmap you create is given an anonymous child bitmap (via the
> successor pointer) that records new writes while the backup is in
> progress. Two things can happen at this point:
> 
> (1) The backup succeeds
> 
> The "abdicate" function is run and "bitmap0" is deleted and the
> anonymous child becomes the new "bitmap0."
> 
> (2) The backup fails
> 
> It's not safe to delete bitmap0, so QEMU merges the anonymous child back
> into bitmap0.
> 
> 
> This means that after the backup you'll always have "bitmap0" attached
> to the same drive.
> 
> It shouldn't be necessary to manually create new incremental bitmap objects.
> 
>> 2. When abdicating the bitmap, it seems leak memory about bitmap->successor.
>>
> 
> I guess this function looks very suspicious, but what's happening in
> actuality is the successor inherits the name of the parent (e.g.
> "bitmap0") and then the parent is freed/deleted.
> 
> This "promotes" the successor to the new standalone bitmap object,
> because both the parent and the successor are part of the list of
> bitmaps attached to the drive object -- we did not lose our reference to
> the successor.
> 

I carefully read the code again, and understand the implementation.
Thank you very much.