On Mon, Feb 28, 2011 at 8:41 PM, Dushyant Bansal <cs5070...@cse.iitd.ac.in> wrote: > On Sunday 27 February 2011 04:19 PM, Stefan Hajnoczi wrote: >> >> On Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal >> <cs5070...@cse.iitd.ac.in> wrote: >>> >>> 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. >>> >> >> If I'm reading this correctly then qemu-img convert is within a few >> seconds of cp(1) for you? >> > > I have collected and attached some more time results for different > operations on a 2.2G image. > qemu-img convert is close to cp. > > qemu(modified): > IO_BUF_SIZE = (2 * 1024 ) > if any sector is non-null, write all sectors
Nice that qemu-img convert isn't that far out by default on raw :). About Google Summer of Code, I have posted my take on applying and want to share that with you and qemu-devel: http://blog.vmsplice.net/2011/03/advice-for-students-applying-to-google.html Stefan
