From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E497C63777 for ; Mon, 30 Nov 2020 17:40:40 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ABF1F206DF for ; Mon, 30 Nov 2020 17:40:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LAPldTLp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABF1F206DF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:34644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjnAE-0001n5-FG for qemu-devel@archiver.kernel.org; Mon, 30 Nov 2020 12:40:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjn6H-00089s-KS for qemu-devel@nongnu.org; Mon, 30 Nov 2020 12:36:36 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55920) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kjn6F-0003u2-HC for qemu-devel@nongnu.org; Mon, 30 Nov 2020 12:36:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606757789; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=EK5KK6HTMrAvEMZyJnwV1NBumb5L5dn5AGOM6lDKcd8=; b=LAPldTLp8ezt4r2vR55PItKkAvwxZRim17C2PI2B7RRGFP+1ooBY1Yj3xQnMoNYs8A4tS2 7fpbSWawLPBWJuTcj/sHDS3pdhlWY0vr9IbXKYE+6WK8r7hnjyv61nfDggkiYhkUKBwJ9Z xlu8QP8Vp6Pc/Uy6pnvwYTp8CWutb5M= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-cEWjqCzUNg-VoPdDHFnptQ-1; Mon, 30 Nov 2020 12:36:24 -0500 X-MC-Unique: cEWjqCzUNg-VoPdDHFnptQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1560F100A641; Mon, 30 Nov 2020 17:36:23 +0000 (UTC) Received: from redhat.com (ovpn-114-242.ams2.redhat.com [10.36.114.242]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0CC525B4A7; Mon, 30 Nov 2020 17:36:20 +0000 (UTC) Date: Mon, 30 Nov 2020 17:36:17 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Markus Armbruster Subject: Re: ImageInfo oddities regarding compression Message-ID: <20201130173617.GJ2039965@redhat.com> References: <87r1ofru4z.fsf@dusky.pond.sub.org> <20201127101405.GA1596141@redhat.com> <20201127103216.GA4736@merkur.fritz.box> <87ft4vq9c1.fsf@dusky.pond.sub.org> <20201127152534.GC4736@merkur.fritz.box> <87eeken3nq.fsf@dusky.pond.sub.org> MIME-Version: 1.0 In-Reply-To: <87eeken3nq.fsf@dusky.pond.sub.org> User-Agent: Mutt/1.14.6 (2020-07-11) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.496, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Kevin Wolf , Denis Plotnikov , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Nov 27, 2020 at 05:52:09PM +0100, Markus Armbruster wrote: > Kevin Wolf 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 :|