Re: [Qemu-devel] Re: KVM call agenda for Jan 25

[Dushyant Bansal <cs5070214@cse.iitd.ac.in>]

>> In cp, it just copies all the disk blocks actually occupied by the file.
>> And, with qemu-img convert, it checks all the sectors and copy those, which
>> contains atleast one non-NUL byte.
>> The better performance of cp over qemu-img convert is the result of overhead
>> of this checking.
>>      
> How did you find out what cp(1) and qemu-img do?
> How does cp(1) know which disk blocks are actually occupied?
>    
I have looked into their source code.
  Yes, that was not correct. cp also checks each block and copy those 
which contains non-null byte.
qemu-img does the same thing with sectors.
>> I tried a few variations:
>> 1. just copy all the sectors without checking
>> So, actual size becomes equal to virtual size.
>>      
> Did that make qemu-img faster for the image file you tested?
>    
No, in fact it becomes slower. I guess it is due to the increase in disk 
write.
>> 2. In is_allocated_sectors,out of n sectors, if any sector has a non-NUL
>> byte then break and copy all n sectors.
>> As expected, resultant raw image was quite large in size.
>>      
> This is kind of like what cp(1) does, except it limits n to 32 KB
> maximum at a time.  Maybe if you add this tweak they will show similar
> performance.  The drawback is that the output image is larger than
> with the current approach.
>
> Stefan
>
>    
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.

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.

Thanks,
Dushyant