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

[Dushyant Bansal]

On Sunday 27 February 2011 04:19 PM, Stefan Hajnoczi wrote:
> 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).
>    
yes, you are right. I was reading from a much older coreutils source.
>    
> > 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

--
Dushyant

results.xls
Description: MS-Excel spreadsheet