[Top][All Lists]
[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 11:04:10 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 |
Am 08.02.2012 10:47, schrieb Ori Mamluk:
> On 08/02/2012 10:55, Kevin Wolf wrote:
>> Am 08.02.2012 07:10, schrieb Ori Mamluk:
>>> On 07/02/2012 17:47, Paolo Bonzini wrote:
>>>>
>>>> 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
> You're right. Currently only Qemu knows.
How could it change later on? If the network is down, qemu can't
communicate it to anyone else, so it stays the only one who knows.
> The problem is that if we move the responsibility to a layer below Qemu
> - then rephub will never know.
> Our (Zerto's) solution for vmware has a different design, but it has 3
> parts relevant to this discussion:
> 1. Tapping to protected writes / read protected volume
> 2. Maintain a bitmap
> 3. Provide cross-VM consistency for recovery.
>
> I want to simplify our design by taking it one step at a time.
> My first goal for Qemu is to have only step 1 - meaning tap all
> protected writes, and be able to read.
> I think it will be simpler for all of us to complete that first, and it
> provides a basic ability (though not optimal) for protection and recovery.
>
> I think using an external streaming mechanism will make the next stages
> impossible.
Well, then we need to discuss all stages now. If you tell only part of
what you're going to do, you'll get a design that will only work for
part of what you need.
Kevin
- Re: [Qemu-devel] [RFC PATCH] replication agent module, (continued)
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Anthony Liguori, 2012/02/07
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Ori Mamluk, 2012/02/07
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Paolo Bonzini, 2012/02/07
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Ori Mamluk, 2012/02/07
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Paolo Bonzini, 2012/02/07
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Ori Mamluk, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Dor Laor, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Stefan Hajnoczi, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Kevin Wolf, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] replication agent module, Ori Mamluk, 2012/02/08
- Re: [Qemu-devel] [RFC PATCH] replication agent module,
Kevin Wolf <=
- Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module), Ori Mamluk, 2012/02/08
- Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module), Stefan Hajnoczi, 2012/02/08
- Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module), Stefan Hajnoczi, 2012/02/08
- Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module), Ori Mamluk, 2012/02/19
- Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module), Paolo Bonzini, 2012/02/20
- [Qemu-devel] BlockDriverState stack and BlockListeners (was: [RFC] Replication agent design), Kevin Wolf, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Paolo Bonzini, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Kevin Wolf, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Paolo Bonzini, 2012/02/21
- Re: [Qemu-devel] BlockDriverState stack and BlockListeners, Kevin Wolf, 2012/02/21