From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=41837 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pt1gk-0000x0-M4
	for qemu-devel@nongnu.org; Fri, 25 Feb 2011 12:42:51 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cs5070214@cse.iitd.ac.in>) id 1Pt1gg-0007cu-4w
	for qemu-devel@nongnu.org; Fri, 25 Feb 2011 12:42:46 -0500
Received: from smtp2.iitd.ernet.in ([202.141.68.44]:46120)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cs5070214@cse.iitd.ac.in>) id 1Pt1gf-0007c9-Ej
	for qemu-devel@nongnu.org; Fri, 25 Feb 2011 12:42:42 -0500
Message-ID: <4D67E9EB.7090606@cse.iitd.ac.in>
Date: Fri, 25 Feb 2011 23:12:03 +0530
From: Dushyant Bansal <cs5070214@cse.iitd.ac.in>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 25
References: <20110124132559.GA25236@x200.localdomain>	<4D3DF7EA.4010807@codemonkey.ws>
	<20110125115727.5f2b495e@doriath>	<20110125120244.5b18863d@doriath>
	<AANLkTi=px6_UZ6vYFm=wvS8aTmecQbA1_Z3ra9UH9ecm@mail.gmail.com>
	<4D43F0F5.10206@cse.iitd.ac.in>
In-Reply-To: <4D43F0F5.10206@cse.iitd.ac.in>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org

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