Am 20.03.2017 um 15:05 schrieb Paolo Bonzini: > > On 20/03/2017 14:35, Peter Lieven wrote: >> Am 20.03.2017 um 14:23 schrieb Paolo Bonzini: >>> On 20/03/2017 14:13, Peter Lieven wrote: >>>> Am 20.03.2017 um 13:47 schrieb Peter Lieven: >>>>> commit 5daa74a6ebce7543aaad178c4061dc087bb4c705 >>>>> Author: Paolo Bonzini <pbonz...@redhat.com> >>>>> Date: Wed Sep 4 19:00:38 2013 +0200 >>>>> >>>>> block: look for zero blocks in bs->file >>>>> >>>>> Reviewed-by: Eric Blake <ebl...@redhat.com> >>>>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> >>>>> Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> >>>>> >>>>> >>>>> It was introduced while introducing bdv_get_block_status. I don't know >>>>> what the real >>>>> >>>>> issue was that was addressed with this patch? >>>> Is it possible that this optimization was added especially for RAW? I was >>>> believing that >>>> raw would forward the get_block_status call to bs->file, but it looks it >>>> doesn't. >>>> If this one here was for RAW would it be an option to move this callout to >>>> the raw-format driver >>>> and remove it from the generic code? >>> It was meant for both raw and qcow2. >> Okay, but as Fam mentioned qcow2 Metadata should know that a cluster is >> zero. Do you remember >> what the issue was? > I said that already---preallocated metadata. Also, at the time > pre-qcow2v3 was more important.
Yes, but Fam said that with preallocated metadata the clusters should be zero, or was that not true before qcow2v3? > > Are you using libiscsi, block devices or files? Its a mixture. raw with libiscsi or lvm and qcow2 and vmdk either with libnfs or on local storage. I stumbled across the issue with lseek on a tmpfs because in the build process for our templates I temporarily have vmdks on a tmpfs and it takes ages before qemu-img convert starts to run (it iterates over every 64kb cluster with that callout to find_allocation and for some reason lseek is very slow on tmpfs). Peter
