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: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).
yes, you are right. I was reading from a much older coreutils source.
I have collected and attached some more time results for different operations on a 2.2G image.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?
qemu-img convert is close to cp. qemu(modified): IO_BUF_SIZE = (2 * 1024 ) if any sector is non-null, write all sectors -- Dushyant
results.xls
Description: MS-Excel spreadsheet