On Tue, Jan 17, 2012 at 3:47 PM, Marcelo Tosatti <mtosa...@redhat.com> wrote: > On Tue, Jan 17, 2012 at 03:05:29PM +0100, Kevin Wolf wrote: >> Am 17.01.2012 14:50, schrieb Marcelo Tosatti: >> > On Tue, Jan 17, 2012 at 02:27:04PM +0100, Kevin Wolf wrote: >> >> Am 13.01.2012 14:14, schrieb Stefan Hajnoczi: >> >>> From: Marcelo Tosatti <mtosa...@redhat.com> >> >>> >> >>> Add support for streaming data from an intermediate section of the >> >>> image chain (see patch and documentation for details). >> >>> >> >>> Signed-off-by: Marcelo Tosatti <mtosa...@redhat.com> >> >>> Signed-off-by: Stefan Hajnoczi <stefa...@linux.vnet.ibm.com> >> >> >> >> I'm afraid that in the review for the previous version I couldn't see >> >> the wood for the trees... This does limit the COR requests issued by >> >> image streaming, but not those issued by the guest. Am I missing >> >> something? This is not what we want, is it? >> > >> > What you mean "limit the COR requests"? >> >> base -> sn1 -> sn2 >> >> You only want to copy the content of sn1 into sn2 and keep base. The >> streaming coroutine is doing the right thing because it checks >> is_allocated_base. However, if it is the guest that reads some data from >> base, COR copies it into sn2 even though it's in the common base file. > > Ah, yes. > >> Maybe streaming shouldn't enable normal COR on images, but instead of >> calling bdrv_co_read it could directly call bdrv_co_copy_on_readv(). > > That would work.
Sounds like a good suggestion. It will prevent the case where a guest is doing heavy read I/O during image streaming with a 'base' and we bloat the destination image file. I'll resend the series with this fix. Stefan
