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. In other words I think this can be optimized. Fam
