Re: [Qemu-block] QCOW2 support for LZO compression

[Kevin Wolf]

Am 26.06.2017 um 11:20 hat Peter Lieven geschrieben:
> >So he chose a different algorithm (zstd). When I asked, he posted a
> >comparison of algorithms (however a generic one and not measured in the
> >context of qemu) that suggests that LZO would be slightly faster, but
> >have a considerable worse compression ratio with the settings that were
> >benchmarked.
> 
> My idea to choose LZO was that it is widely available and available in
> any distro you can think of. We already have probing for it in configure.
> My concern with ZSTD would be that it seems there are no packages
> available for most distros and that it seems to be multi-threaded. I don't
> know if this will cause any trouble?

The availability and that we already link against LZO is a good point. I
think we want to avoid a situation where compressed qcow2 files can't be
read by binaries of popular distributions - after all, downloadable
images are an important use case for compressed images.

> >I think it's clear that if there is any serious interest in compression,
> >we'll want to support at least one more algorithm. What we still need to
> >evaluate is which one(s) to take, and whether a simple incompatible flag
> >in the header like in Den's patch is enough or whether we should add a
> >whole new header field for the compression algorithm (like we already
> >have for encryption).
> 
> From my side there clearly is interest in optimizing the compression. Its
> even possible to speed up zlib by 3-4x times by choosing other parameters
> for deflate which unfortunately are not compatible with our inflate settings.
> 
> I don't know if its worth creating a new header field. Even if we spent to 
> bits
> in the end (one for LZO and one for ZSDT). I think this wouldn't hurt. 
> However,
> there are likely to pop up new compression algorithms in the future and
> a header would be more flexible.

That we could just use different parameters is an important hint that
maybe we don't just need bits to select an algorithm, but also some
space for parameters for the selected algorithm. In this case I think we
need a header change anyway.

> I just don't want to make it too complicated and as you pointed out
> compression is not that interesting for most people - maybe due to its
> speed.

In fact, I think it could be the poor integration in qemu. Compressed
images might be more appealing if you couldn't only write compressed
data with special-case operations like 'qemu-img convert', but just give
an option that you want all writes to be compressed and then use it like
any other image.

Kevin