[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V5 10/10] block/qcow2: add compress info to imag
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH V5 10/10] block/qcow2: add compress info to image specific info |
Date: |
Tue, 25 Jul 2017 16:55:07 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
On 07/25/2017 09:41 AM, Peter Lieven wrote:
> Signed-off-by: Peter Lieven <address@hidden>
> ---
> block/qcow2.c | 7 +++++++
> qapi/block-core.json | 6 +++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> +++ b/qapi/block-core.json
> @@ -68,6 +68,9 @@
> # @encrypt: details about encryption parameters; only set if image
> # is encrypted (since 2.10)
> #
> +# @compress: details about parameters for compressed clusters; only set if
> +# the compress format header extension is present (since 2.11)
Thinking aloud:
I still think this is better as "only set if the image uses compressed
headers" (similar to encrypt). That is, I would like this output to be
present even when opening legacy deflate/0/12 images.
But thinking more, what I am REALLY asking for is "if any cluster is
compressed, then this information is present; if nothing is compressed,
the choice of compression header doesn't matter". But we don't have a
quick-and-dirty way to tell if an image has any compressed clusters,
short of examining every L2 map (including maps inside internal snapshots).
Hmm - we already have 'Dirty bit' and 'Corrupt bit' as
incompatible_features that can quickly identify certain image
properties; do we want another bit set to 1 for images known to use
compressed clusters? Or even make it an auto-clear bit (or even a pair
of auto-clear bits: one to designate that this image was written by a
new-enough qemu that promises to mark the image if any compressed
clusters exist, and the other is set only if such clusters do exist;
that way, if both bits are clear, we know we have to walk L2 tables to
look for compressed clusters, but if the first bit is set, then the
second bit is reliable)?
So maybe this means we are still debating spec ideas. Kevin, do you
want to chime in?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH V5 01/10] specs/qcow2: add compress format extension, (continued)
[Qemu-devel] [PATCH V5 03/10] block/qcow2: parse compress create options, Peter Lieven, 2017/07/25
[Qemu-devel] [PATCH V5 06/10] block/qcow2: simplify ret usage in qcow2_create, Peter Lieven, 2017/07/25
[Qemu-devel] [PATCH V5 02/10] qapi/block-core: add Qcow2Compress parameters, Peter Lieven, 2017/07/25
[Qemu-devel] [PATCH V5 09/10] block/qcow2: add lzo compress format, Peter Lieven, 2017/07/25
[Qemu-devel] [PATCH V5 10/10] block/qcow2: add compress info to image specific info, Peter Lieven, 2017/07/25
- Re: [Qemu-devel] [PATCH V5 10/10] block/qcow2: add compress info to image specific info,
Eric Blake <=
[Qemu-devel] [PATCH V5 07/10] block/qcow2: optimize qcow2_co_pwritev_compressed, Peter Lieven, 2017/07/25
[Qemu-devel] [PATCH V5 08/10] block/qcow2: start using the compress format extension, Peter Lieven, 2017/07/25
[Qemu-devel] [PATCH V5 04/10] qemu-img: add documentation for compress settings, Peter Lieven, 2017/07/25
[Qemu-devel] [PATCH V5 05/10] block/qcow2: read and write the compress format extension, Peter Lieven, 2017/07/25