[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Re: KVM call agenda for Jan 25 |
Date: |
Sat, 26 Feb 2011 14:05:51 +0000 |
On Fri, Feb 25, 2011 at 5:42 PM, Dushyant Bansal
<address@hidden> 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