qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@openvz.org>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, kwolf@redhat.com, eblake@redhat.com,
	jsnow@redhat.com, stefanha@redhat.com, famz@redhat.com,
	mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset
Date: Thu, 30 Jun 2016 12:12:29 +0300	[thread overview]
Message-ID: <5774E27D.60003@openvz.org> (raw)
In-Reply-To: <1467272042-5195-1-git-send-email-vsementsov@virtuozzo.com>

On 06/30/2016 10:34 AM, Vladimir Sementsov-Ogievskiy wrote:
> After loading bitmap from image and setting IN_USE flag in it's header,
> corresponding data (bitmap table and data clusters) becomes inconsistent
> and is no longer needed. It is better to free bitmap table and
> corresponding clusters from the image immediately after loading the
> bitmap than free them when the bitmap is saved, or deleted or set
> non-persistent.
>
> For now it is impossible to store only bitmap header without bitmap
> table, as specification requires it. Storing zeroed bitmap table (one or
> more clusters) is the only option to implement the behaviour similar to
> specified above.
>
> The same problem is for just storing empty bitmaps.
>
> This patch allows storing only bitmap header for empty bitmaps.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>
> Additional note. Should we also allow here bitmap_table_offset = 1, like
> in bitmap table, for the bitmap with all bits set? I am not sure that it
> is needed at all, but just to keep the company..
>
>   docs/specs/qcow2.txt | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
> index 80cdfd0..9826222 100644
> --- a/docs/specs/qcow2.txt
> +++ b/docs/specs/qcow2.txt
> @@ -435,9 +435,12 @@ Structure of a bitmap directory entry:
>                       Offset into the image file at which the bitmap table
>                       (described below) for the bitmap starts. Must be aligned to
>                       a cluster boundary.
> +                    Zero value means that bitmap table is not allocated and the
> +                    bitmap should be considered as empty (all bits are zero).
>   
>            8 - 11:    bitmap_table_size
> -                    Number of entries in the bitmap table of the bitmap.
> +                    Number of entries in the bitmap table of the bitmap. It
> +                    must be zero if bitmap_table_offset is zero.
>   
>           12 - 15:    flags
>                       Bit
NACK

no guys, we can not make this change at the moment.
We do have QEMU available in the field which is working
with the currently specified format.

Den

  reply	other threads:[~2016-06-30  9:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30  7:34 [Qemu-devel] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset Vladimir Sementsov-Ogievskiy
2016-06-30  9:12 ` Denis V. Lunev [this message]
2016-06-30 16:40   ` John Snow
2016-06-30 17:23     ` Denis V. Lunev
2016-07-01  8:12       ` Kevin Wolf
2016-07-01  8:39         ` Vladimir Sementsov-Ogievskiy

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=5774E27D.60003@openvz.org \
    --to=den@openvz.org \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    /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).