On Fri, Feb 25, 2011 at 5:42 PM, Dushyant Bansal <cs5070...@cse.iitd.ac.in> wrote: > 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.
Great, it's good to hear from you. > cp faster than qemu-img convert Yes, I've experienced that too. > 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. How did you find out what cp(1) and qemu-img do? How does cp(1) know which disk blocks are actually occupied? > I tried a few variations: > 1. just copy all the sectors without checking > So, actual size becomes equal to virtual size. Did that make qemu-img faster for the image file you tested? > 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. This is kind of like what cp(1) does, except it limits n to 32 KB maximum at a time. Maybe if you add this tweak they will show similar performance. The drawback is that the output image is larger than with the current approach. Stefan