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

[Kevin Wolf]

Am 01.04.2011 14:36, schrieb Anthony Liguori:
> 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?

I don't like it much (and I think neither do you), but I agree that
blockdev won't be there tomorrow, so I wouldn't object to it.

>>> 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.

Yes and no. If you have the read and the write to same sector, then it
would be undefined whether the read returns the old or the new data. But
if the write completes successfully, the sector must have been updated.
I doubt that this is something that guests usually do.

However, we're not operating on a sector level, but on a cluster level
here. So the guest could actually access two different sectors and still
get its write request overwritten by the COR.

Kevin