From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52780 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtS3n-0002tX-5T for qemu-devel@nongnu.org; Sat, 26 Feb 2011 16:52:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtS3e-0002jm-If for qemu-devel@nongnu.org; Sat, 26 Feb 2011 16:52:18 -0500 Received: from smtp1.iitd.ernet.in ([202.141.68.45]:46544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtS3d-0001oX-Ds for qemu-devel@nongnu.org; Sat, 26 Feb 2011 16:52:10 -0500 Message-ID: <4D6975B0.4060309@cse.iitd.ac.in> Date: Sun, 27 Feb 2011 03:20:40 +0530 From: Dushyant Bansal 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> <4D43F0F5.10206@cse.iitd.ac.in> <4D67E9EB.7090606@cse.iitd.ac.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org >> 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 have looked into their source code. Yes, that was not correct. cp also checks each block and copy those which contains non-null byte. qemu-img does the same thing with sectors. >> 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? > No, in fact it becomes slower. I guess it is due to the increase in disk write. >> 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 > > Disk block size is usually 512 bytes and in qemu-img, sector size is also 512B. And, this change would copy n sectors even if only one of them actually contains data (while cp checks and copies one block(=sector) at a time). Therefore, it will end up writing more data than cp. virtual size: 10G (10737418240 bytes) disk size: 569M convert-> original time 0m52.522s convert-> modified (resultant disk size: 5.3G) time 2m12.744s cp time 0m51.724s (same disk size) --------------------------------------------------------------------------- virtual size: 10G (10737418240 bytes) disk size: 3.6G convert-> original time 1m52.249s convert-> modified (resultant disk size: 7.1G) time 3m2.891s cp time 1m55.320s (same disk size) --------------------------------------------------------------------------- In these results, we can see that resultant disk size has increased. Thanks, Dushyant