On Mon, Feb 6, 2012 at 2:07 AM, Stefan G. Weichinger <lists@xxxxxxxx> 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
