[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [Questions] Several questions about increm
From: |
Rudy Zhang |
Subject: |
Re: [Qemu-block] [Qemu-devel] [Questions] Several questions about incremental backup |
Date: |
Tue, 26 Jan 2016 10:33:29 +0800 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
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.