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
