From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv486-0002ho-UC for qemu-devel@nongnu.org; Wed, 08 Feb 2012 04:48:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv482-00026b-HI for qemu-devel@nongnu.org; Wed, 08 Feb 2012 04:47:58 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:63634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv482-00026K-C9 for qemu-devel@nongnu.org; Wed, 08 Feb 2012 04:47:54 -0500 Received: by bkue19 with SMTP id e19so130505bku.4 for ; Wed, 08 Feb 2012 01:47:53 -0800 (PST) Message-ID: <4F3244C2.1040604@zerto.com> Date: Wed, 08 Feb 2012 11:47:46 +0200 From: Ori Mamluk 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> In-Reply-To: <4F323875.1000000@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Kevin Wolf Cc: dlaor@redhat.com, =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV?= =?UTF-8?B?16g=?= , qemu-devel@nongnu.org, Yair Kuszpet , Paolo Bonzini 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. 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.