qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] replication agent module


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module
Date: Wed, 08 Feb 2012 09:55:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

Am 08.02.2012 07:10, schrieb Ori Mamluk:
> On 07/02/2012 17:47, Paolo Bonzini wrote:
>> On 02/07/2012 03:48 PM, Ori Mamluk wrote:
>>>> The current streaming code in QEMU only deals with the former.
>>>> Streaming to a remote server would not be supported.
>>>>
>>> I need it at the same time. The Rephub reads either the full volume or
>>> parts of, and concurrently protects new IOs.
>>
>> Why can't QEMU itself stream the full volume in the background, and 
>> send that together with any new I/O?  Is it because the rephub knows 
>> which parts are out-of-date and need recovery?  In that case, as a 
>> first approximation the rephub can pass the sector at which streaming 
>> should start.
> Yes - it's because rephub knows. The parts that need recovery may be a 
> series of random IOs that were lost because of a network outage 
> somewhere along the replication pipe.
> Easy to think of it as a bitmap holding the not-yet-replicated IOs. The 
> rephub occasionally reads those areas to 'sync' them, so in effect the 
> rephub needs read access - it's not really to trigger streaming from an 
> offset.

So how does the rephub know which areas were touched by lost requests?
Isn't qemu the only one who could know what it sent?

Kevin



reply via email to

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