qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC QCOW2 compression speed


From: Eric Blake
Subject: Re: [Qemu-devel] RFC QCOW2 compression speed
Date: Fri, 24 Feb 2017 15:15:55 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 02/24/2017 01:54 PM, Peter Lieven wrote:
> 
> Changing the compression level via environment or a QCOW2 parameter is not a 
> big deal. However, it helps not that much regarding speed. What helps is 
> increasing the window size, but this is an incompatible change. And if we go 
> for an incompatible change I would think about using a better compression 
> algorithm than zlib deflate.

Indeed, lzma (think xz), or zstd, or $compression_of_the_day... may be
better, and it may be disk-image dependent which algorithm is best. It
sounds like we need to improve the qcow2 spec to add a header extension
that describes the current compression algorithm and parameters; if
omitted the image uses zlib with fixed window size, but if present, we
can put everything we need to be able to choose other compression
tunings and be able to decompress (still, it has to be an all-or-none).
We'd also need to set an incompatible_features flag if the compression
header extension is present with non-default values so that older qemu
don't go corrupting the compressed data.  And then you start having to
worry about modularity (do you compile qemu with support for all
compression libraries, or can you pick and choose which ones to compile
in at the risk of which images you can't open, or do you figure out how
to dlopen the right libraries as needed...)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]