From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53699 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PteC8-0000pu-Dg for qemu-devel@nongnu.org; Sun, 27 Feb 2011 05:49:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PteBy-0005wM-NC for qemu-devel@nongnu.org; Sun, 27 Feb 2011 05:49:36 -0500 Received: from mail-yi0-f45.google.com ([209.85.218.45]:52071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PteBy-0005wE-Hh for qemu-devel@nongnu.org; Sun, 27 Feb 2011 05:49:34 -0500 Received: by yib19 with SMTP id 19so374047yib.4 for ; Sun, 27 Feb 2011 02:49:33 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D6975B0.4060309@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> <4D6975B0.4060309@cse.iitd.ac.in> Date: Sun, 27 Feb 2011 10:49:33 +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 Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal wrote: > Disk block size is usually 512 bytes and in qemu-img, sector size is also > 512B. And, this change would =A0copy n sectors even if only one of them > actually contains data (while cp checks and copies one block(=3Dsector) a= t a > time). Therefore, it will end up writing more data than cp. cp(1) from GNU coreutils 8.5 works in units of 32 KB on my system. It reads 32 KB and checks for all zeroes. If there are all zeroes, it seeks ahead 32 KB in the output file. Otherwise it writes the entire 32 KB. You can check what cp(1) is doing using strace(1). > virtual size: 10G (10737418240 bytes) > disk size: 569M > > convert-> original > time =A0 =A00m52.522s > > convert-> modified (resultant disk size: 5.3G) > time =A0 =A02m12.744s > > cp > time =A0 =A00m51.724s (same disk size) > -------------------------------------------------------------------------= -- > virtual size: 10G (10737418240 bytes) > disk size: 3.6G > > convert-> original > time =A0 =A01m52.249s > > convert-> modified (resultant disk size: 7.1G) > time =A0 =A03m2.891s > > cp > time =A0 =A01m55.320s (same disk size) > -------------------------------------------------------------------------= -- > In these results, we can see that resultant disk size has increased. If I'm reading this correctly then qemu-img convert is within a few seconds of cp(1) for you? Stefan