On Mon, Feb 6, 2012 at 2:07 AM, Stefan G. Weichinger <lists(a)xunil.at> wrote:
Am 06.02.2012 03:24, schrieb Trey Dockendorf:
> I wouldn't consider this definitive, but I wrote an article doing
> tests on qcow2 with the variables being preallocation and caching.
> Essentially preallocation + no-cache is the fastest. Article here,
>
http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/. As of
> virt-manager-0.9.0 the only way to generate the qcow2 with
> preallocation is via command line. Details of how are in the article.
Additional question:
Doesn't pre-allocation lose its meaning as soon as the image-file is
fully allocated (I mean as soon as it is as big as its maximum size was
defined at start)?
Sending response back to list incase someone finds it useful.
Preallocation works so that when you create a 100GB image it takes up
100GB from the start. This helps performance because without
preallocation the disk would only take up space of whatever is stored
on it. So each time you add files the filesystem as to grow the
image. With qcow2 the preallocation is just metadata. I've found
that ls -lh will show the size correctly but something like "df -h"
won't reflect the size of those images, nor will "du -h".
- Trey