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: 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



reply via email to

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