From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38576 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtKmU-0004Re-Mz for qemu-devel@nongnu.org; Sat, 26 Feb 2011 09:06:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtKmP-0005US-1H for qemu-devel@nongnu.org; Sat, 26 Feb 2011 09:05:58 -0500 Received: from mail-gw0-f46.google.com ([74.125.83.46]:46867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtKmO-0005U2-V6 for qemu-devel@nongnu.org; Sat, 26 Feb 2011 09:05:52 -0500 Received: by gwj20 with SMTP id 20so1535725gwj.33 for ; Sat, 26 Feb 2011 06:05:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D67E9EB.7090606@cse.iitd.ac.in> References: <20110124132559.GA25236@x200.localdomain> <4D3DF7EA.4010807@codemonkey.ws> <20110125115727.5f2b495e@doriath> <20110125120244.5b18863d@doriath> <4D43F0F5.10206@cse.iitd.ac.in> <4D67E9EB.7090606@cse.iitd.ac.in> Date: Sat, 26 Feb 2011 14:05:51 +0000 Message-ID: Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 25 From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dushyant Bansal Cc: qemu-devel@nongnu.org On Fri, Feb 25, 2011 at 5:42 PM, Dushyant Bansal wrote: > On Saturday 29 January 2011 04:20 PM, Dushyant Bansal wrote: >> >> Or this: which is faster, qemu-img convert -f =A0-O >> =A0 =A0or cp =A0? =A0What a= bout for >> raw images, shouldn't that be the same speed as cp(1)? =A0Poke around >> the source code, profile it, understand what it's doing, think about >> ways to improve it. =A0No 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. =A0If 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, whi= ch > contains atleast one non-NUL byte. > The better performance of cp over qemu-img convert is the result of overh= ead > 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