[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH RESEND v4] drive-mirror: add increm

From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH RESEND v4] drive-mirror: add incremental mode
Date: Tue, 12 Mar 2019 11:58:35 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 3/12/19 9:43 AM, Eric Blake wrote:
> On 3/12/19 3:19 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> So one important point about incremental backups is that you can
>>> actually do them incrementally: The bitmap is effectively cleared at the
>>> beginning of the backup process (a successor bitmap is installed that is
>>> cleared and receives all changes; at the end of the backup, it either
>>> replaces the old bitmap (on success) or is merged into it (on failure)).
>>>   Therefore, you can do the next incremental backup by using the same 
>>> bitmap.
>> Hmm, I heard in some other thread that Eric finally decided to always start
>> backup on copied bitmap in libvirt, so this logic is skipped. Do we need it
>> for mirror? Sorry if I'm wrong, Eric, am I?
> You are correct that my current libvirt patches do incremental backup
> mode with a temporary bitmap (so regardless of whether the temporary
> bitmap is cleared on success or left alone is irrelevant, the temporary
> bitmap goes away afterwards). But just because libvirt isn't using that
> particular feature of qemu's incremental backups does not excuse qemu
> from not thinking about other clients that might be impacted by doing
> incremental backup with a live bitmap, where qemu management of the
> bitmap matters.

I'd prefer adding SYNC=DIFFERENTIAL to intuit that the bitmap isn't
modified after use, if there's no reason to add an actual "incremental"
mode to mirror.

Then it would be fine for mirror to implement differential and not
incremental, and still use the bitmap.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]