[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC QCOW2 compression speed
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] RFC QCOW2 compression speed |
Date: |
Fri, 24 Feb 2017 12:36:12 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 |
On 02/24/17 10:33, Peter Lieven wrote:
> Hi,
>
>
> i have been experimenting with deflate compression paramters in the past and
> found that the values chosen
>
> in QCOW2 are not that optimal. In fact creation of compressed QCOW2 is very
> slow.
I agree, I find it slow as well.
> And especially for backups
>
> compression would be good, but its so slow thats almost infeasible to use.
>
>
> The current settings to inflateinit2 are compression level 6
> (Z_DEFAULT_COMPRESSION) and windowBits 12.
>
> Increasing windowBits increases speed and yields better compression. Lowering
> the compression level increases
>
> speed, but results in worse compression.
>
>
> The issue here is that changing windowBits would (in theory) require a change
> of the parameters to deflateInit2 in
>
> decompression which means that this change would make QCOW2 images
> incompatible.
>
>
> As for discussion here is my experiment of compression a Ubuntu1604
> installation in ram.
>
> level 6, windowBits 12 -> 42 seconds, 470MB size
>
> level 6, windowBits 15 -> 35 seconds, 448MB size
>
> level 1, windowBits 12 -> 30 seconds, 500MB size
>
> level 1, windowBits 15 -> 15 seconds, 483MB size
>
>
> Strange enough decompression works with unchanged parameters for all files.
> But the documentation of zlib claims
>
> it should produce an error if a windowBits 15 stream is deflated with a
> smaller windowBits parameter.
>
>
> What are your thoughts in introducing a switch and/or feature to use
> alternate settings for inflate?
>
> If we need to introduce an incompatible feature for the bigger windowBits
> might it be worth thinking of using
>
> an alternate compression algorithm like LZ4?
If the compression level was exposed with a command line option (and/or
an environment variable, a la $GZIP), I would welcome it. I have
frequently missed this feature, but I always figured it wouldn't be
important enough to bother block people with it.
Thanks
Laszlo