Am 27.03.2017 um 17:06 schrieb Paolo Bonzini: > > On 27/03/2017 15:21, Peter Lieven wrote: >>>> 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). >>> Ok, thanks. Perhaps it's worth benchmarking tmpfs specifically. Apart >>> from the system call overhead (which does not really matter if you're >>> going to do a read), lseek on other filesystems should not be any slower >>> than read. >> Okay, but the even the read is not really necessary if the metadata is >> correct? > Yeah, what I mean is: > > - if you're going to do a read of non-zero blocks, the lseek you do > before reading those blocks should not matter. > > - if you're going to skip the read of non-zero blocks, the lseek you do > is always going to be faster than reading them and then checking with > buffer_is_nonzero. > >> Would it be an idea to introduce an inverse flag live BDRV_BLOCK_NOT_ZERO >> for cases where we know that there is really DATA and thus can avoid the >> second callout? > How would you know that a block is nonzero?
I would trust the metadata. At least for VMDK and QCOW2v3. Bad idea? Peter
