On 06/27/2017 04:27 PM, Peter Lieven wrote: > Am 27.06.2017 um 15:20 schrieb Daniel P. Berrange: >> On Tue, Jun 27, 2017 at 02:34:07PM +0200, Peter Lieven wrote: >>> this patch adds a new compression_algorithm option when creating >>> qcow2 images. >>> The current default for the compresison algorithm is zlib and zlib >>> will be >>> used when this option is omitted (like before). >>> >>> If the option is specified e.g. with: >>> >>> qemu-img create -f qcow2 -o compression_algorithm=zlib image.qcow2 1G >> IMHO we should introduce a nested struct "compress" struct to hold >> the format >> name, and any other format specific arguments, in a way that maps >> nicely to >> any future QAPI representmatch of create options. eg >> >> { 'enum': 'BlockdevQcow2CompressFormat', >> 'data': [ 'zlib', 'lzo' ] } >> >> { 'union': 'BlockdevQcow2Compress', >> 'base': { 'format': 'BlockdevQcow2CompressFormat' }, >> 'discriminator': 'format', >> 'data': { 'zlib': 'BlockdevQcow2CompressZLib', >> 'lzo': 'BlockdevQcow2CompressLZO'} } >> >> so it would map to >> >> qemu-img create -f qcow2 -o compress.format=zlib image.qcow2 1G >> >> and let us have other compress.XXXX options specific to each format > > Or would it be possible to start with just a compress.level (int) > parameter. > In fact that would be sufficient for almost all formats (or better use > algorithms?). > The windowBits can be default to -15 in the future. It seems the old > choice of -12 > was just not optimal. We just have to use it for backwards > compatiblity if the compress > options are not specified. > > Peter > We can put generic parameters on top (in generic header) but put algorithm-dependent container inside. This could be viable for the future to avoid incompatible format changes.
Den