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

[Avi Kivity <avi@redhat.com>]

  On 09/07/2010 05:57 PM, Anthony Liguori wrote:
>> I agree that streaming should be generic, like block migration.  The
>> trivial generic implementation is:
>>
>> void bdrv_stream(BlockDriverState* bs)
>> {
>>      for (sector = 0; sector<  bdrv_getlength(bs); sector += n) {
>>          if (!bdrv_is_allocated(bs, sector,&n)) {
>
> Three problems here.  First problem is that bdrv_is_allocated is 
> synchronous. 

Put the whole thing in a thread.

> The second problem is that streaming makes the most sense when it's 
> the smallest useful piece of work whereas bdrv_is_allocated() may 
> return a very large range.
>
> You could cap it here but you then need to make sure that cap is at 
> least cluster_size to avoid a lot of unnecessary I/O.

That seems like a nice solution.  You probably want a multiple of the 
cluster size to retain efficiency.

>
> The QED streaming implementation is 140 LOCs too so you quickly end up 
> adding more code to the block formats to support these new interfaces 
> than it takes to just implement it in the block format.

bdrv_is_allocated() already exists (and is needed for commit), what else 
is needed?  cluster size?

> Third problem is that  streaming really requires being able to do zero 
> write detection in a meaningful way.  You don't want to always do zero 
> write detection so you need another interface to mark a specific write 
> as a write that should be checked for zeros.

You can do that in bdrv_stream(), above, before the actual write, and 
call bdrv_unmap() if you detect zeros.

-- 
error compiling committee.c: too many arguments to function