qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH] mirror: add sync mode incremental


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror
Date: Mon, 8 May 2017 17:07:18 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0


On 05/08/2017 05:02 PM, Denis V. Lunev wrote:
> On 05/08/2017 10:35 PM, Stefan Hajnoczi wrote:
>> On Thu, May 04, 2017 at 12:54:40PM +0200, Daniel Kucera wrote:
>>
>> Seems like a logical extension along the same lines as the backup block
>> job's dirty bitmap sync mode.
>>
>>> parameter bitmap chooses existing dirtymap instead of newly created
>>> in mirror_start_job
>>>
>>> Signed-off-by: Daniel Kucera <address@hidden>
> Can you pls describe the use case pls in a bit more details.
> 
> For now this could be a bit strange:
> - dirty bitmap, which can be found via bdrv_create_dirty_bitmap
>   could be read-only or read-write, i.e. being modified by writes
>   or be read-only, which should not be modified. Thus adding
>   r/o bitmap to the mirror could result in interesting things.
> 

This patch as it was submitted does not put the bitmap into a read-only
mode; it leaves it RW and modifies it as it processes the mirror command.

Though you do raise a good point; this bitmap is now in-use by a job and
should not be allowed to be deleted by the user, but our existing
mechanism treats a locked bitmap as one that is also in R/O mode. This
would be a different use case.

> Minimally we should prohibit usage of r/o bitmaps this way.
> 
> So, why to use mirror, not backup for the case?
> 

My guess is for pivot semantics.

> Den
> 



reply via email to

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