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