qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Max Reitz <mreitz@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, John Snow <jsnow@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [PATCH qemu 2/4] drive-mirror: add support for conditional and always bitmap sync modes
Date: Fri, 02 Oct 2020 10:23:33 +0200	[thread overview]
Message-ID: <1601623989.wcs44caouc.astroid@nora.none> (raw)
In-Reply-To: <5af05c55-3e19-23d6-ee87-554090b56310@redhat.com>

On October 1, 2020 7:01 pm, Max Reitz wrote:
> On 22.09.20 11:14, Fabian Grünbichler wrote:
>> From: John Snow <jsnow@redhat.com>
>> 
>> Teach mirror two new tricks for using bitmaps:
>> 
>> Always: no matter what, we synchronize the copy_bitmap back to the
>> sync_bitmap. In effect, this allows us resume a failed mirror at a later
>> date, since the target bdrv should be exactly in the state referenced by
>> the bitmap.
>> 
>> Conditional: On success only, we sync the bitmap. This is akin to
>> incremental backup modes; we can use this bitmap to later refresh a
>> successfully created mirror, or possibly re-try the whole failed mirror
>> if we are able to rollback the target to the state before starting the
>> mirror.
>> 
>> Based on original work by John Snow.
>> 
>> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
>> ---
>>  block/mirror.c | 28 ++++++++++++++++++++--------
>>  blockdev.c     |  3 +++
>>  2 files changed, 23 insertions(+), 8 deletions(-)
>> 
>> diff --git a/block/mirror.c b/block/mirror.c
>> index d64c8203ef..bc4f4563d9 100644
>> --- a/block/mirror.c
>> +++ b/block/mirror.c
> 
> [...]
> 
>> @@ -1781,8 +1793,8 @@ static BlockJob *mirror_start_job(
>>      }
>>  
>>      if (s->sync_mode == MIRROR_SYNC_MODE_BITMAP) {
>> -        bdrv_merge_dirty_bitmap(s->dirty_bitmap, s->sync_bitmap,
>> -                                NULL, &local_err);
>> +        bdrv_dirty_bitmap_merge_internal(s->dirty_bitmap, s->sync_bitmap,
>> +                                         NULL, true);
> 
> (Sorry for not catching it in the previous version, but) this hunk needs
> to go into patch 1, doesn’t it?

yes. this was a result of keeping the original patches #1 and #2, and 
doing the cleanup on-top as separate patches. I missed folding it into 
the first instead of (now combined) second patch.

> Or, rather...  Do we need it at all?  Is there anything that would
> prohibit just moving this merge call to before the set_busy call?
> (Which again is probably something that should be done in patch 1.)
> 
> (If you decide to keep calling *_internal, I think it would be nice to
> add a comment above the call stating why we have to use *_internal here
> (because the sync bitmap is busy now), and why it’s safe to do so
> (because blockdev.c and/or mirror_start_job() have already checked the
> bitmap).  But if it’s possible to do the merge before marking the
> sync_bitmap busy, we probably should rather do that.)

I think it should be possible for this instance. for the other end of 
the job, merging back happens before setting the bitmap to un-busy, so we 
need to use _internal there. will add a comment for that one why we are 
allowed to do so.

> 
>>          if (local_err) {
>>              goto fail;
>>          }
>> diff --git a/blockdev.c b/blockdev.c
>> index 6baa1a33f5..0fd30a392d 100644
>> --- a/blockdev.c
>> +++ b/blockdev.c
>> @@ -3019,6 +3019,9 @@ static void blockdev_mirror_common(const char *job_id, BlockDriverState *bs,
>>          if (bdrv_dirty_bitmap_check(bitmap, BDRV_BITMAP_ALLOW_RO, errp)) {
>>              return;
>>          }
>> +    } else if (has_bitmap_mode) {
>> +        error_setg(errp, "Cannot specify bitmap sync mode without a bitmap");
>> +        return;
>>      }
> 
> This too I would move into patch 1.

Ack.



  reply	other threads:[~2020-10-02  8:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  9:14 [PATCH qemu 0/4] mirror: implement incremental and bitmap modes Fabian Grünbichler
2020-09-22  9:14 ` [PATCH qemu 1/4] drive-mirror: add support for sync=bitmap mode=never Fabian Grünbichler
2020-10-01 14:18   ` Max Reitz
2020-10-02  7:06   ` Markus Armbruster
2020-10-02  8:45     ` Fabian Grünbichler
2020-10-02 12:07       ` Markus Armbruster
2020-09-22  9:14 ` [PATCH qemu 2/4] drive-mirror: add support for conditional and always bitmap sync modes Fabian Grünbichler
2020-10-01 17:01   ` Max Reitz
2020-10-02  8:23     ` Fabian Grünbichler [this message]
2020-09-22  9:14 ` [PATCH qemu 3/4] mirror: move some checks to qmp Fabian Grünbichler
2020-10-01 17:16   ` Max Reitz
2020-09-22  9:14 ` [PATCH qemu 4/4] iotests: add test for bitmap mirror Fabian Grünbichler
2020-10-01 17:31   ` Max Reitz
2020-10-02  8:23     ` Fabian Grünbichler
2020-10-13 14:31       ` 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=1601623989.wcs44caouc.astroid@nora.none \
    --to=f.gruenbichler@proxmox.com \
    --cc=armbru@redhat.com \
    --cc=jsnow@redhat.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 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).