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

[Peter Lieven]

Am 26.06.2017 um 11:57 schrieb 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.

As long as the default remains gzip I don't see any issues. If you choose
a different algorithm, you should know what you are doing.

> > > 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.

The issue is, you don't know in advance how much space will be needed for the 
paramters.
Maybe it would be simpler to have different settings for a compression 
algorithm threated
as different algorithms. Like zstd-fast, zstd, zstd-slow, gzip, lzo, lzo-slow 
etc.

> > 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.

Then we should start to improve that.

Peter