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
