qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dushyant Bansal
Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 25
Date: Fri, 25 Feb 2011 23:12:03 +0530
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6

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.

cp faster than qemu-img convert

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.

I tried a few variations:
1. just copy all the sectors without checking
So, actual size becomes equal to virtual size.
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.

Looking forward to your comments.

Thanks,
Dushyant




reply via email to

[Prev in Thread] Current Thread [Next in Thread]