From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42558 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OszgK-0007T2-Se for qemu-devel@nongnu.org; Tue, 07 Sep 2010 11:02:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OszgG-0007ou-96 for qemu-devel@nongnu.org; Tue, 07 Sep 2010 11:01:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3519) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OszgF-0007oV-UL for qemu-devel@nongnu.org; Tue, 07 Sep 2010 11:01:52 -0400 Message-ID: <4C8653E9.2070905@redhat.com> Date: Tue, 07 Sep 2010 17:02:01 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration References: <4C864118.7070206@linux.vnet.ibm.com> <4C864D65.6090004@redhat.com> <4C86510E.9010303@linux.vnet.ibm.com> In-Reply-To: <4C86510E.9010303@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , qemu-devel , Stefan Hajnoczi Am 07.09.2010 16:49, schrieb Anthony Liguori: >> Shouldn't it be a runtime option? You can use the very same image with >> copy-on-read or copy-on-write and it will behave the same (execpt for >> performance), so it's not an inherent feature of the image file. >> > > The way it's implemented in QED is that it's a compatible feature. This > means that implementations are allowed to ignore it if they want to. > It's really a suggestion. Well, the point is that I see no reason why an image should contain this suggestion. There's really nothing about an image that could reasonably indicate "use this better with copy-on-read than with copy-on-write". It's a decision you make when using the image. > So yes, you could have a run time switch that overrides the feature bit > on disk and either forces copy-on-read on or off. > > Do we have a way to pass block drivers run time options? We'll get them with -blockdev. Today we're using colons for format specific and separate -drive options for generic things. >> Doing it this way has the additional advantage that you need no image >> format support for this, so we could implement copy-on-read for other >> formats, too. >> > > To do it efficiently, it really needs to be in the format for the same > reason that copy-on-write is part of the format. Copy-on-write is not part of the format, it's a way of how to use this format. Backing files are part of the format, and they are used for both copy-on-write and copy-on-read. Any driver implementing a format that has support for backing files should be able to implement copy-on-read. > You need to understand the cluster boundaries in order to optimize the > metadata updates. Sure, you can expose interfaces to the block layer to > give all of this info but that's solving the same problem for doing > block level copy-on-write. > > The other challenge is that for copy-on-read to be efficiently, you > really need a format that can distinguish between unallocated sectors > and zero sectors and do zero detection during the copy-on-read > operation. Otherwise, if you have a 10G virtual disk with a backing > file that's 1GB is size, copy-on-read will result in the leaf being 10G > instead of ~1GB. That's a good point. But it's not a reason to make the interface specific to QED just because other formats would probably not implement it as efficiently. Kevin