From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S20v4-00054E-Iu for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:47:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S20uy-0007DA-NB for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:47:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S20uy-0007Cy-F0 for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:47:08 -0500 Message-ID: <4F4B8957.7060404@redhat.com> Date: Mon, 27 Feb 2012 14:47:03 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> <1329930815-7995-2-git-send-email-fsimonce@redhat.com> <4F4B6AFE.6090601@redhat.com> <4F4B6D99.3090305@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] Add blkmirror block driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, Federico Simoncelli , mtosatti@redhat.com, qemu-devel@nongnu.org On 02/27/2012 02:09 PM, Stefan Hajnoczi wrote: > > Non-incremental mode is "pre-copy" migration. It would stream in the > > background from the source to the destination. In this case: > > > > - you need to differentiate streaming writes from other writes. When > > streaming, you do not want to issue spurious writes to the source; > > > > - you can skip streaming anything that has been written to the > > destination already. This means that you need: 1) a bitmap similar to > > is_allocated; 2) to widen writes to a cluster; 3) serialization similar > > to copy-on-read. > > > > I'm not yet sure how much of this will be generalized in the block layer > > and block/stream.c, and how much will be specific to blkmirror, but in > > general none of this applies to blkverify. > > Agreed but I'm not sure it has to do with blkmirror either. blkmirror > and blkverify perform the same function except that blkverify mirrors > reads too and checks that they match. > > Who knows when and if pre-copy will be (re)implemented, it's not a > good argument to say let's duplicate block mirroring because we're not > sure about the design of a feature feature yet which might want to > hook in here. It's not a duplicate, it just happens that two very simple drivers share 1 operation out of 4 (open, read, write, flush). There are other differences, for example: 1) blkverify hardcodes raw for one format and auto-detects the other. blkmirror needs to have a specified format for both, and I don't think starting another bikeshedding discussion on blkverify backwards compatibility is a good idea; 2) blkverify doesn't flush the raw file; 3) blkverify in the future could add callbacks to create snapshots or load/save imgstate, and forward them to the test file; this doesn't make sense for blkmirror. Paolo