Re: [libvirt] [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration

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.

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