qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: KVM call agenda for Jan 25


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 25
Date: Sun, 27 Feb 2011 10:49:33 +0000

On Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal
<address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]