Re: [Qemu-block] callout to *file in bdrv_co_get_block_status

[Fam Zheng]

On Fri, 03/17 12:20, Peter Lieven wrote:
> Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
> >
> > On 17/03/2017 12:11, Peter Lieven wrote:
> >>>> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables 
> >>>> in the VMDK or QCOW2?
> >>> It provides additional information, for example it works better with
> >>> prealloc=metadata.
> >> Okay, understood. Can you imagine of a away to conditionally avoid this 
> >> second callout? In my case we have an additional
> >> lseek for each cluster. For a 20GB file this are approx. 327k calls to 
> >> lseek. And if the file has no preallocated metadata
> >> it will likely not improve anything. And even if the metadata is 
> >> prealloced what is the allocation status of the clusters?
> > If the metadata is preallocated, cluster will (or should) show up as
> > zero, speeding up the copy.
> 
> Okay, in this case the second call out to *file will not happen. It only 
> happens if the metadata says it contains data.
> So where does it actually help?
> 
> The condition is: (ret & BDRV_BLOCK_DATA) && !(ret & BDRV_BLOCK_ZERO) && (ret 
> & BDRV_BLOCK_OFFSET_VALID))
> 
> So from my view it can only have any effect if the metadata returns 
> BDRV_BLOCK_DATA, but the protocol driver returns
> BDRV_BLOCK_ZERO.
> 
> This can only happen if I partially write to a cluster, or am I wrong here?

I think you have a point. The metadata should have said BDRV_BLOCK_ZERO if
protocol would say BDRV_BLOCK_ZERO - there is no reason the format driver cannot
know.

Fam