qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC PATCH] qed: add support for Copy-on-Read


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]