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: Peter Lieven
Subject: Re: [Qemu-devel] RFC QCOW2 compression speed
Date: Fri, 24 Feb 2017 20:54:36 +0100

> Am 24.02.2017 um 12:36 schrieb Laszlo Ersek <address@hidden>:
> 
> 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.

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.

Peter


reply via email to

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