From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv3Ft-0008PD-50 for qemu-devel@nongnu.org; Wed, 08 Feb 2012 03:52:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv3Fp-0002Tz-0z for qemu-devel@nongnu.org; Wed, 08 Feb 2012 03:51:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv3Fo-0002Tv-NC for qemu-devel@nongnu.org; Wed, 08 Feb 2012 03:51:52 -0500 Message-ID: <4F323875.1000000@redhat.com> Date: Wed, 08 Feb 2012 09:55:17 +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> In-Reply-To: <4F3211D0.3070502@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 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