On Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal <cs5070...@cse.iitd.ac.in> wrote: > 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.
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 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? Stefan