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. Paolo
