On Sunday 27 February 2011 04:19 PM, Stefan Hajnoczi wrote:
> On Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal
> <cs5070214@cse.iitd.ac.in>  wrote:
>    
>> Disk block size is usually 512 bytes and in qemu-img, sector size is also
>> 512B. And, this change would  copy n sectors even if only one of them
>> actually contains data (while cp checks and copies one block(=sector) at a
>> time). Therefore, it will end up writing more data than cp.
>>      
> cp(1) from GNU coreutils 8.5 works in units of 32 KB on my system.  It
> reads 32 KB and checks for all zeroes.  If there are all zeroes, it
> seeks ahead 32 KB in the output file.  Otherwise it writes the entire
> 32 KB.
>
> You can check what cp(1) is doing using strace(1).
>    
yes, you are right. I was reading from a much older coreutils source.
>    
>> virtual size: 10G (10737418240 bytes)
>> disk size: 569M
>>
>> convert->  original
>> time    0m52.522s
>>
>> convert->  modified (resultant disk size: 5.3G)
>> time    2m12.744s
>>
>> cp
>> time    0m51.724s (same disk size)
>> ---------------------------------------------------------------------------
>> virtual size: 10G (10737418240 bytes)
>> disk size: 3.6G
>>
>> convert->  original
>> time    1m52.249s
>>
>> convert->  modified (resultant disk size: 7.1G)
>> time    3m2.891s
>>
>> cp
>> time    1m55.320s (same disk size)
>> ---------------------------------------------------------------------------
>> In these results, we can see that resultant disk size has increased.
>>      
> If I'm reading this correctly then qemu-img convert is within a few
> seconds of cp(1) for you?
>    
I have collected and attached some more time results for different 
operations on a 2.2G image.
qemu-img convert is close to cp.

qemu(modified):
IO_BUF_SIZE = (2 * 1024 )
if any sector is non-null, write all sectors

--
Dushyant