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 <[EMAIL PROTECTED]> 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 ?
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
