From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53643 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ot0Ge-0004e8-Mc for qemu-devel@nongnu.org; Tue, 07 Sep 2010 11:39:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ot0Ga-0006JF-6V for qemu-devel@nongnu.org; Tue, 07 Sep 2010 11:39:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23022) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ot0GZ-0006J9-UZ for qemu-devel@nongnu.org; Tue, 07 Sep 2010 11:39:24 -0400 Message-ID: <4C865CB5.8070508@redhat.com> Date: Tue, 07 Sep 2010 17:39:33 +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> <4C8653E9.2070905@redhat.com> <4C86560D.9030308@linux.vnet.ibm.com> <4C86584C.9070406@redhat.com> <4C865A7C.4050003@linux.vnet.ibm.com> In-Reply-To: <4C865A7C.4050003@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 17:30, schrieb Anthony Liguori: > On 09/07/2010 10:20 AM, Kevin Wolf wrote: >> Am 07.09.2010 17:11, schrieb Anthony Liguori: >>> Copy-on-read is, in many cases, a property of the backing file because >>> it suggests that the backing file is either very slow or potentially >>> volatile. >>> >> The simple copy-on-read without actively streaming the rest of the image >> is not enough anyway for volatile backing files. >> > > But as a web site owner, it's extremely useful for me to associate > copy-on-read with an image because it significantly reduces my bandwidth. > > I have a hard time believing this isn't a valuable use-case and not one > that's actually pretty common. As a web site user, I don't necessarily want you to control the behaviour of my qemu. :-) But I do see your point there. >>> You really can't do as good of a job in the block layer because you have >>> very little info about the characteristics of the disk image. >>> >> I'm not saying that the generic block layer should implement >> copy-on-read. I just think that it should pass a run-time option to the >> driver - maybe just a BDRV_O_COPY_ON_READ flag - instead of having the >> information in the image file. From a user perspective it should look >> the same for qed, qcow2 and whatever else (like copy-on-write today) >> > > Okay, the only place I'm disagreeing slightly is that I think an image > format should be able to request copy_on_read such that the default > behavior if an explicit flag isn't specified is to do what the image > suggests we do. Maybe we can agree on that. I'm not completely decided yet if allowing the image to contain such a hint is a good or a bad thing. Kevin