All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org
Cc: kwolf@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org,
	den@openvz.org
Subject: Re: [PATCH v2 1/2] qcow2-bitmaps: fix qcow2_can_store_new_dirty_bitmap
Date: Fri, 25 Oct 2019 14:50:48 +0200	[thread overview]
Message-ID: <e54561aa-d653-5df4-0379-083ddc7b9657@redhat.com> (raw)
In-Reply-To: <20191014115126.15360-2-vsementsov@virtuozzo.com>


[-- Attachment #1.1: Type: text/plain, Size: 981 bytes --]

On 14.10.19 13:51, Vladimir Sementsov-Ogievskiy wrote:
> qcow2_can_store_new_dirty_bitmap works wrong, as it considers only
> bitmaps already stored in the qcow2 image and ignores persistent
> BdrvDirtyBitmap objects.
> 
> So, let's instead count persistent BdrvDirtyBitmaps. We load all qcow2
> bitmaps on open, so there should not be any bitmap in the image for
> which we don't have BdrvDirtyBitmaps version. If it is - it's a kind of
> corruption, and no reason to check for corruptions here (open() and
> close() are better places for it).
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>  block/qcow2-bitmap.c | 41 ++++++++++++++++++-----------------------
>  1 file changed, 18 insertions(+), 23 deletions(-)

Am I right in interpreting qcow2_load_dirty_bitmaps() in such a way that
every persistent dirty bitmap will cause a runtime dirty bitmap to be
created?

If so:

Reviewed-by: Max Reitz <mreitz@redhat.com>


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

  reply	other threads:[~2019-10-25 12:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-14 11:51 [PATCH v2 0/2] fix qcow2_can_store_new_dirty_bitmap Vladimir Sementsov-Ogievskiy
2019-10-14 11:51 ` [PATCH v2 1/2] qcow2-bitmaps: " Vladimir Sementsov-Ogievskiy
2019-10-25 12:50   ` Max Reitz [this message]
2019-10-25 12:56     ` Vladimir Sementsov-Ogievskiy
2019-12-09 16:32   ` Max Reitz
2019-10-14 11:51 ` [PATCH v2 2/2] iotests: add 269 to check maximum of bitmaps in qcow2 Vladimir Sementsov-Ogievskiy
2019-10-25 13:12   ` Max Reitz
2019-11-16  9:41     ` Vladimir Sementsov-Ogievskiy
2019-10-14 11:52 ` [PATCH v2 0/2] fix qcow2_can_store_new_dirty_bitmap Vladimir Sementsov-Ogievskiy
2019-10-25  9:57 ` [bugfix ping] " Vladimir Sementsov-Ogievskiy
2019-12-02 14:09   ` [bugfix ping2] " Vladimir Sementsov-Ogievskiy
2019-12-09 16:30     ` Max Reitz
2019-12-09 17:58       ` Max Reitz
2019-12-09 22:03         ` Eric Blake
2019-12-10  8:11           ` Max Reitz
2019-12-10 13:24             ` Max Reitz
2019-12-10 20:27               ` John Snow
2019-12-11  8:10                 ` 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=e54561aa-d653-5df4-0379-083ddc7b9657@redhat.com \
    --to=mreitz@redhat.com \
    --cc=den@openvz.org \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --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 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.