From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43516 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5dT2-0001mf-3c for qemu-devel@nongnu.org; Fri, 01 Apr 2011 08:28:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5dT0-000740-FV for qemu-devel@nongnu.org; Fri, 01 Apr 2011 08:28:43 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:43180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5dT0-00073j-AB for qemu-devel@nongnu.org; Fri, 01 Apr 2011 08:28:42 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p31CDBVs023418 for ; Fri, 1 Apr 2011 06:13:11 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p31CSdiD101010 for ; Fri, 1 Apr 2011 06:28:40 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p31CSdtJ011132 for ; Fri, 1 Apr 2011 06:28:39 -0600 Message-ID: <4D95C4F2.2000006@us.ibm.com> Date: Fri, 01 Apr 2011 07:28:34 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1301533714-28997-1-git-send-email-aliguori@us.ibm.com> <20110401094210.GB25832@stefanha-thinkpad.localdomain> In-Reply-To: <20110401094210.GB25832@stefanha-thinkpad.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH] qed: add support for Copy-on-Read List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel@nongnu.org On 04/01/2011 04:42 AM, Stefan Hajnoczi wrote: > On Wed, Mar 30, 2011 at 08:08:34PM -0500, Anthony Liguori wrote: >> When creating an image using qemu-img, just pass '-o copy_on_read' and then >> whenever QED reads from a backing file, it will write the block to the QED >> file after the read completes ensuring that you only fetch from the backing >> device once. >> >> This is very useful for streaming images over a slow connection. >> >> This isn't ready for merge yet as it's not playing nice with synchronize I/O. > What is the issue here? Streaming had issues with aio contexts and > synchronous I/O emulation but copy-on-read by itself looks safe to me. Here's the scenario that fails for me although I'm starting to suspect block/curl as the real culprit. qemu-img create -f qed -o copy_on_read -b http://linux.nssl.noaa.gov/fedora/fedora/linux/releases/14/Fedora/x86_64/iso/Fedora-14-x86_64-DVD.iso cached_iso.img qemu -cdrom cache_iso.img -boot d And I have a patch that does a bunch of synchronous reads of the disk. >> I think it's fairly easy to do the same thing in qcow2 by just hooking adding >> some logic after bdrv_aio_write() to call back into qcow2 with a synchronous >> I/O write in the backing file case. Thoughts on whether that would actually >> work? > Why not do the follow-up .bdrv_aio_writev() for qcow2 too? I don't see > a reason to do it synchronously. Oh, I assumed with coroutines that that would be the preference in qcow2. If not, AIO is just as good for me :-) Regards, Anthony Liguori > Stefan