[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] RFC QCOW2 compression speed
From: |
Peter Lieven |
Subject: |
[Qemu-devel] RFC QCOW2 compression speed |
Date: |
Fri, 24 Feb 2017 10:33:32 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
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. 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?
Thanks,
Peter
- [Qemu-devel] RFC QCOW2 compression speed,
Peter Lieven <=