Am 07.09.2010 17:30, schrieb Anthony Liguori:
On 09/07/2010 10:20 AM, Kevin Wolf wrote:
Am 07.09.2010 17:11, schrieb Anthony Liguori:
Copy-on-read is, in many cases, a property of the backing file because it suggests that the backing file is either very slow or potentially volatile.
The simple copy-on-read without actively streaming the rest of the image is not enough anyway for volatile backing files.
But as a web site owner, it's extremely useful for me to associate copy-on-read with an image because it significantly reduces my bandwidth.
I have a hard time believing this isn't a valuable use-case and not one that's actually pretty common.
As a web site user, I don't necessarily want you to control the behaviour of my qemu. :-) But I do see your point there.
You really can't do as good of a job in the block layer because you have very little info about the characteristics of the disk image.
I'm not saying that the generic block layer should implement copy-on-read. I just think that it should pass a run-time option to the driver - maybe just a BDRV_O_COPY_ON_READ flag - instead of having the information in the image file. From a user perspective it should look the same for qed, qcow2 and whatever else (like copy-on-write today)
Okay, the only place I'm disagreeing slightly is that I think an image format should be able to request copy_on_read such that the default behavior if an explicit flag isn't specified is to do what the image suggests we do.
Maybe we can agree on that. I'm not completely decided yet if allowing the image to contain such a hint is a good or a bad thing. Kevin