All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Alberto Garcia <berto@igalia.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] specs/qcow2: Clarify that compressed clusters have the COPIED bit reset
Date: Tue, 10 Apr 2018 11:31:33 -0500	[thread overview]
Message-ID: <271b88fe-6d19-fee3-cdc7-f76c046958dc@redhat.com> (raw)
In-Reply-To: <74552e1d6e858d3159cb0c0e188e80bc9248e337.1523376013.git.berto@igalia.com>

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

On 04/10/2018 11:05 AM, Alberto Garcia wrote:
> Compressed clusters are not supposed to have the COPIED bit set, but
> this is not made explicit in the specs, so let's document it.
> 
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
>  docs/interop/qcow2.txt | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
> index feb711fb6a..8e1547ded2 100644
> --- a/docs/interop/qcow2.txt
> +++ b/docs/interop/qcow2.txt
> @@ -400,10 +400,10 @@ L2 table entry:
>                62:   0 for standard clusters
>                      1 for compressed clusters
>  
> -              63:   0 for a cluster that is unused or requires COW, 1 if its
> -                    refcount is exactly one. This information is only accurate
> -                    in L2 tables that are reachable from the active L1
> -                    table.
> +              63:   0 for clusters that are unused, compressed or require COW.
> +                    1 for standard clusters whose refcount is exactly one.
> +                    This information is only accurate in L2 tables
> +                    that are reachable from the active L1 table.

This matches what qemu outputs, so the question becomes whether it is
technically necessary to make this requirement mandatory for 3rd-party
implementations.  But I'm in favor of the tighter wording, as it gets
rather hairy to check whether exactly one compressed cluster is
occupying a host cluster, plus I don't want to think about what happens
if a compressed cluster with the bit set crosses a host cluster boundary
(does it mean that compressed cluster is the only [remaining] source of
data for BOTH host clusters at once, where both the head of the first
host cluster and tail of the second host cluster is unused?)

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

  reply	other threads:[~2018-04-10 16:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-10 16:05 [Qemu-devel] [PATCH 0/2] Minor fixes about compressed clusters with OFLAG_COPIED Alberto Garcia
2018-04-10 16:05 ` [Qemu-devel] [PATCH 1/2] Fix error message " Alberto Garcia
2018-04-10 16:18   ` Eric Blake
2018-04-10 16:45     ` Alberto Garcia
2018-04-10 16:05 ` [Qemu-devel] [PATCH 2/2] specs/qcow2: Clarify that compressed clusters have the COPIED bit reset Alberto Garcia
2018-04-10 16:31   ` Eric Blake [this message]
2018-04-13 14:38 ` [Qemu-devel] [PATCH 0/2] Minor fixes about compressed clusters with OFLAG_COPIED Max Reitz

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=271b88fe-6d19-fee3-cdc7-f76c046958dc@redhat.com \
    --to=eblake@redhat.com \
    --cc=berto@igalia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.