qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Lieven
Subject: Re: [Qemu-block] callout to *file in bdrv_co_get_block_status
Date: Fri, 17 Mar 2017 12:20:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

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?

Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]