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

[Peter Lieven <pl@kamp.de>]

Am 17.03.2017 um 15:51 schrieb Paolo Bonzini:
>
> On 17/03/2017 12:24, Fam Zheng wrote:
>> On Fri, 03/17 12:16, Paolo Bonzini wrote:
>>>
>>> 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.
>> I think from qemu-img convert's perspective, it doesn't care about the *file
>> status if the metadata already speaks, because, like you said, the data shows up
>> as zeroes.
> That's already the case: *file is only examined if the metadata  says
> BDRV_BLOCK_DATA=1, BDRV_BLOCK_ZERO=0.

Maybe Fam meant in qemu-img this info is not that necessary because it will skip zeroes inside
a datablock anyway. I don't know why the lseek is soo slow, but the optimization could be to identify
the case where this extra info of the *file containing zeroes is really useful and then only call out for
it in those cases.

Peter

>
> Paolo