qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Denis Plotnikov <dplotnikov@virtuozzo.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: ImageInfo oddities regarding compression
Date: Mon, 30 Nov 2020 17:36:17 +0000	[thread overview]
Message-ID: <20201130173617.GJ2039965@redhat.com> (raw)
In-Reply-To: <87eeken3nq.fsf@dusky.pond.sub.org>

On Fri, Nov 27, 2020 at 05:52:09PM +0100, Markus Armbruster wrote:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > Am 27.11.2020 um 13:21 hat Markus Armbruster geschrieben:
> >> >> I fell down this (thankfully shallow) rabbit hole because we also have
> >> >> 
> >> >>     { 'enum': 'MultiFDCompression',
> >> >>       'data': [ 'none', 'zlib',
> >> >>                 { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }
> >> >> 
> >> >> I wonder whether we could merge them into a common type.
> >> 
> >> Looks like we could: current code would never report the additional
> >> value 'none'.  Introspection would show it, though.  Seems unlikely to
> >> cause trouble.  Observation, not demand.
> >
> > Forgot to comment on this one...
> >
> > Technically we could probably, but would it make sense? Support for
> > compression formats has to be implemented separately for both cases, so
> > that they currently happen to support the same list is more of a
> > coincidence.
> >
> > If we ever add a third compression format to qcow2, would we add the
> > same format to migration, too, or would we split the schema into two
> > types again?
> 
> I figure if a compression method is worth adding to one, it's probably
> worth adding to the other.

I'm not entirely sure about that, as compression algorithms have different
tradeoffs.

For migration compression we're streaming large volumes of data in a live
session, both compression and decompression speed is very important.

For qcow2 we're handling relative small discrete blocks (a qcow2
cluster at a time) and decompression speed is much more important that
compression speed, since we generally compress once out of band, and
decompress many times while live.

So we could see new compression methods desired for migration that are
not relevant for qcow2, or vica-verca.

> Having two separate enums isn't too bad.  A third has been proposed[*],
> but I hope we can reuse migration's existing enum there.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2020-11-30 17:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27 10:06 ImageInfo oddities regarding compression Markus Armbruster
2020-11-27 10:14 ` Daniel P. Berrangé
2020-11-27 10:32   ` Kevin Wolf
2020-11-27 12:21     ` Markus Armbruster
2020-11-27 15:25       ` Kevin Wolf
2020-11-27 16:52         ` Markus Armbruster
2020-11-30 17:36           ` Daniel P. Berrangé [this message]
2020-11-30 17:24     ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201130173617.GJ2039965@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dplotnikov@virtuozzo.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).