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

[Anthony Liguori <aliguori@us.ibm.com>]

On 04/01/2011 06:11 AM, Kevin Wolf wrote:
> Am 31.03.2011 03:08, schrieb Anthony Liguori:
>> 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.
> As you probably know, I don't agree with the interface. Copy on read
> should be first and foremost a runtime option. It's okay to fetch the
> default for this option from the image file, but it's not the right
> primary interface.

That's the main reason I posted this.  I wanted to revisit that 
discussion and see if we're any close to having a primary interface for 
this.

I think blockdev is still a ways off.  Would a -drive 
file=image.img,cor=on make sense as an intermediate mechanism?

>> 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.
> Like Stefan I'm not sure what you mean here.
>
> One problem that I see is that if you have a concurrent write request
> from the guest, the COR write request may overwrite the guest's request,
> which is obviously wrong. Is this what you mean?

Yes, I think you're right here but I don't think this is the issue.  But 
surely the semantics of a simultaneous read/write are undefined at least 
on the read side.  I guess having the write be undefined is unexpected.

Regards,

Anthony Liguori

> Kevin