From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXCft-0004iz-8M for qemu-devel@nongnu.org; Thu, 16 Jun 2011 09:31:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXCfo-00056s-Tv for qemu-devel@nongnu.org; Thu, 16 Jun 2011 09:31:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXCfo-000564-E9 for qemu-devel@nongnu.org; Thu, 16 Jun 2011 09:31:52 -0400 Message-ID: <4DFA004E.9010001@redhat.com> Date: Thu, 16 Jun 2011 15:08:30 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1308075511-4745-1-git-send-email-stefanha@linux.vnet.ibm.com> <4DF9F899.5050301@redhat.com> <4DF9FBE4.9080300@redhat.com> In-Reply-To: <4DF9FBE4.9080300@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Image streaming and live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Dor Laor , Stefan Hajnoczi , jes sorensen , Marcelo Tosatti , qemu-devel@nongnu.org, Adam Litke Am 16.06.2011 14:49, schrieb Avi Kivity: > On 06/16/2011 03:35 PM, Kevin Wolf wrote: >> * Image streaming is a normal image file plus copy-on-read plus a >> background task that copies data from the source image > > Or a block-mirror started in degraded mode. At least not in the same configuration as with live block copy: You don't want to write to the source, you only want to read from it when the destination doesn't have the data yet. >> * Live block copy is a block-mirror of two normal image files plus a >> background task that copies data from the source image > > = block-mirror started in degraded mode >> The right solution is probably to implement COR and the background task >> in generic block layer code (no reason to restrict it to QED) and use it >> for both image streaming and live block copy. (This is a bit more >> complicated than it may sound here because guest writes must always take >> precedence over a copy - but doing complicated things is an even better >> reason to do it in a common place instead of duplicating) > > Or in a block-mirror block format driver - generic code need not be > involved. Might be an option. In this case generic code is only involved with the stacking of BlockDriverStates, which is already implemented (but requires -blockdev for a sane way to configure things). Kevin