From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv4Kb-0005nl-9H for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:00:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv4KV-0004oY-7T for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:00:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv4KU-0004oS-Rw for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:00:47 -0500 Message-ID: <4F32489A.80307@redhat.com> Date: Wed, 08 Feb 2012 11:04:10 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F31153E.9010205@codemonkey.ws> <4F311839.9030709@redhat.com> <4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com> <4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com> <4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com> <4F323875.1000000@redhat.com> <4F3244C2.1040604@zerto.com> In-Reply-To: <4F3244C2.1040604@zerto.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ori Mamluk Cc: dlaor@redhat.com, =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV?= =?UTF-8?B?16g=?= , qemu-devel@nongnu.org, Yair Kuszpet , Paolo Bonzini 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