qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/18] block/mirror: Add active-sync mirroring


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 00/18] block/mirror: Add active-sync mirroring
Date: Sat, 16 Sep 2017 16:02:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 2017-09-14 17:42, Stefan Hajnoczi wrote:
> On Wed, Sep 13, 2017 at 08:18:52PM +0200, Max Reitz wrote:
>> There may be a couple of things to do on top of this series:
>> - Allow switching between active and passive mode at runtime: This
>>   should not be too difficult to implement, the main question is how to
>>   expose it to the user.
>>   (I seem to recall we wanted some form of block-job-set-option
>>   command...?)
>>
>> - Implement an asynchronous active mode: May be detrimental when it
>>   comes to convergence, but it might be nice to have anyway.  May or may
>>   not be complicated to implement.
> 
> Ideally the user doesn't have to know about async vs sync.  It's an
> implementation detail.
> 
> Async makes sense during the bulk copy phase (e.g. sync=full) because
> guest read/write latencies are mostly unaffected.  Once the entire
> device has been copied there are probably still dirty blocks left
> because the guest touched them while the mirror job was running.  At
> that point it definitely makes sense to switch to synchronous mirroring
> in order to converge.

Makes sense, but I'm not sure whether it really is just an
implementation detail.  If you're in the bulk copy phase in active/async
mode and you have enough write requests with the target being slow
enough, I suspect you might still not get convergence then (because the
writes to the target yield for a long time while ever more write
requests pile up) -- so then you'd just shift the dirty tracking from
the bitmap to a list of requests in progress.

And I think we do want the bulk copy phase to guarantee convergence,
too, usually (when active/foreground/synchronous mode is selected).  If
we don't, then that's a policy decision and would be up to libvirt, as I
see it.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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