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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Fri, Feb 25, 2011 at 5:42 PM, Dushyant Bansal
<cs5070214@cse.iitd.ac.in> wrote:
> On Saturday 29 January 2011 04:20 PM, Dushyant Bansal wrote:
>>
>> Or this: which is faster, qemu-img convert -f<format>  -O<format>
>> <src-image>  <dst-image>  or cp<src-image>  <dst-image>?  What about for
>> raw images, shouldn't that be the same speed as cp(1)?  Poke around
>> the source code, profile it, understand what it's doing, think about
>> ways to improve it.  No need to do everything, just doing part of this
>> will give you background on QEMU's block layer.
>>
>> Contributing patches is a good way get up to speed and show your
>> skills.  If time doesn't permit that, just think about the problem and
>> how you intend to solve it, and feel free to bounce ideas off me.
>>
>
> I explored 'qemu-img create and convert' and got a basic understanding of
> how they work.

Great, it's good to hear from you.

> cp faster than qemu-img convert

Yes, I've experienced that too.

> For raw->raw
> 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 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?

> 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