Re: [Qemu-devel] QCow v2

["André Braga" <meianoite@gmail.com>]

I'm not sure about LZMA, but I'd really like to see this experiment
done with LZO. The compression/decompression speeds of LZO are
fantastic, and I really don't care to shave off every bit of
compressible information as long as it doesn't impact performance as
hard as cqcow does.

There will naturally be people willing to sacrifice speed for space,
so having multiple compression algorithms each targetting a different
scenario would be great.

Something like LZO for compression/decompression speed, LZMA for
maximum speed saving, and deflate (zlib) as a compromise between the
two.

I'm only not sure if 4k is an optimal block size. Given a block size
it's trivial to map which clusters belong to which block, adding that
to a trivial caching algorithm which keeps the "k" latest accessed
blocks in RAM and lazily flushes them to the image (either forced by a
predefined flush frequency of perhaps 2 flushes per minute or by
necessity, to bring another block into the cache; the candidate to go
away could be chosen by LRU).

Just curious: how does CQCOW handle block writes which produce a
compressed cluster larger than the original? Say, the data entropy of
a given cluster increased. Will CQCOW move every block a bit forward
(big, big, big overhead), will it mark the previously occupied space
as free and keep a block index and a bitmap of holes in the file and
then use a best-fit algorithm to choose a block to put in there in the
future (which would mean image-internal fragmentation), or does it
leave the management details to the host file system (and then one has
no control about how fragmented the image gets, unless one runs a
defrag utility on the host)? Is there another solution I'm missing?

Thanks for the attention,
A.



On 7/11/06, Christian MICHON <christian.michon@gmail.com> wrote:
> ok, I did this experiment (long and painful).
>
> a XP2003/SP1 qemu guest required 964,231,168 bytes qcow image.
> zlib qcow image became 459,686,368 bytes.
> lzma estimation (4k clusters) is 437,038,838 bytes.
>
> Yes, 5% are still gained, but the time to get the lzma'ed qcow is
> disastrous (especially on systems with anti-virus and anti-malware).
>
> Do you still think it's worth it ?
>