|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [RFC PATCH] qed: add support for Copy-on-Read |
Date: | Fri, 01 Apr 2011 07:28:34 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |