On 20/03/2017 03:46, Fam Zheng wrote: > 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.
That's true of qcow2, but many formats (including raw :)) don't know about BDRV_BLOCK_ZERO. Paolo
