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
