[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
From: |
Dushyant Bansal |
Subject: |
Re: [Qemu-devel] Re: KVM call agenda for Jan 25 |
Date: |
Fri, 25 Feb 2011 23:12:03 +0530 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 |
On Saturday 29 January 2011 04:20 PM, Dushyant Bansal wrote:
Or this: which is faster, qemu-img convert -f<format> -O<format>
<src-image> <dst-image> or cp<src-image> <dst-image>? What about for
raw images, shouldn't that be the same speed as cp(1)? Poke around
the source code, profile it, understand what it's doing, think about
ways to improve it. No need to do everything, just doing part of this
will give you background on QEMU's block layer.
Contributing patches is a good way get up to speed and show your
skills. If time doesn't permit that, just think about the problem and
how you intend to solve it, and feel free to bounce ideas off me.
I explored 'qemu-img create and convert' and got a basic understanding
of how they work.
cp faster than qemu-img convert
For raw->raw
In cp, it just copies all the disk blocks actually occupied by the file.
And, with qemu-img convert, it checks all the sectors and copy those,
which contains atleast one non-NUL byte.
The better performance of cp over qemu-img convert is the result of
overhead of this checking.
I tried a few variations:
1. just copy all the sectors without checking
So, actual size becomes equal to virtual size.
2. In is_allocated_sectors,out of n sectors, if any sector has a non-NUL
byte then break and copy all n sectors.
As expected, resultant raw image was quite large in size.
Looking forward to your comments.
Thanks,
Dushyant
- Re: [Qemu-devel] Re: KVM call agenda for Jan 25,
Dushyant Bansal <=