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.