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
