qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: John Snow <jsnow@redhat.com>,
	kwolf@redhat.com, qemu-block@nongnu.org, armbru@redhat.com,
	qemu-devel@nongnu.org, mnestratov@virtuozzo.com,
	mreitz@redhat.com, nshirokovskiy@virtuozzo.com,
	stefanha@redhat.com, pbonzini@redhat.com, den@openvz.org,
	dev@acronis.com
Subject: Re: [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API
Date: Tue, 26 Dec 2017 15:07:15 +0800	[thread overview]
Message-ID: <20171226070715.GF9418@lemon> (raw)
In-Reply-To: <d5df7e51-fe6b-da89-9bf1-9b03c1afdd67@virtuozzo.com>

On Wed, 12/20 11:20, Vladimir Sementsov-Ogievskiy wrote:
> external backup:
> 
> 0. we have active_disk and attached to it dirty bitmap bitmap0
> 1. qmp blockdev-add tmp_disk (backing=active_disk)
> 2. guest fsfreeze
> 3. qmp transaction:
>         - block-dirty-bitmap-add node=active_disk name=bitmap1
>         - block-dirty-bitmap-disable node=active_disk name=bitmap0
>         - blockdev-backup drive=active_disk target=tmp_disk sync=none
> 4. guest fsthaw
> 5. (? not designed yet) qmp blockdev-add filter_node - special filter node
> over tmp_disk for synchronization of nbd-reads and backup(sync=none) cow
> requests (like it is done in block/replication)
> 6. qmp nbd-server-start
> 7. qmp nbd-server-add filter_node (there should be possibility of exporting
> bitmap of child node filter_node->tmp_disk->active_disk->bitmap0)
> 
> then, external tool can connect to nbd server and get exported bitmap and
> read data (including bitmap0) accordingly to nbd specification.
> (also, external tool may get a merge of several bitmaps, if we already have
> a sequence of them)
> then, after backup finish, what can be done:
> 
> 1. qmp block-job-cancel device=active_disk (stop our backup(sync=none))
> 2. qmp nbd-server-stop (or qmp nbd-server-remove filter_node)
> 3. qmp blockdev-remove filter_node
> 4. qmp blockdev-remove tmp_disk
> 
> on successful backup, you can drop old bitmap if you want (or do not drop
> it, if you need to keep sequence of disabled bitmaps):
> 1. block-dirty-bitmap-remove node=active_disk name=bitmap0
> 
> on failed backup, you can merge bitmaps, to make it look like nothing
> happened:
> 1. qmp transaction:
>        - block-dirty-bitmap-merge node=active_disk name-source=bitmap1
> name-target=bitmap0

Being done in a transaction, will merging a large-ish bitmap synchronously hurt
the responsiveness? Because we have the BQL lock held here which pauses all
device emulation.

Have you measured how long it takes to merge two typical bitmaps. Say, for a 1TB
disk?

Fam

  parent reply	other threads:[~2017-12-26  7:07 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 16:20 [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API Vladimir Sementsov-Ogievskiy
2017-11-13 16:20 ` [Qemu-devel] [PATCH 1/4] block/dirty-bitmap: add lock to bdrv_enable/disable_dirty_bitmap Vladimir Sementsov-Ogievskiy
2017-11-13 17:50   ` [Qemu-devel] [PATCH 1/4 for-2.11?] " Eric Blake
2017-11-16  7:56     ` Vladimir Sementsov-Ogievskiy
2017-11-16  7:59     ` Vladimir Sementsov-Ogievskiy
2017-11-13 16:20 ` [Qemu-devel] [PATCH 2/4] qapi: add block-dirty-bitmap-enable/disable Vladimir Sementsov-Ogievskiy
2017-11-13 16:20 ` [Qemu-devel] [PATCH 3/4] qmp: transaction support for block-dirty-bitmap-enable/disable Vladimir Sementsov-Ogievskiy
2017-11-13 16:20 ` [Qemu-devel] [PATCH 4/4] qapi: add block-dirty-bitmap-merge Vladimir Sementsov-Ogievskiy
2017-12-26  8:41   ` Vladimir Sementsov-Ogievskiy
2017-11-15 21:20 ` [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API John Snow
2017-11-16  8:17   ` Vladimir Sementsov-Ogievskiy
2017-11-17  3:10     ` John Snow
2017-11-17  8:22       ` Vladimir Sementsov-Ogievskiy
2017-11-17 21:35         ` John Snow
2017-11-21 17:23           ` Kevin Wolf
2017-11-22  0:10             ` John Snow
2017-11-22  8:40               ` Vladimir Sementsov-Ogievskiy
2017-12-07 11:56               ` [Qemu-devel] [Qemu-block] " Kashyap Chamarthy
2017-12-07 17:33                 ` Kevin Wolf
2017-12-08  9:35                   ` Kashyap Chamarthy
2017-12-07 22:47                 ` John Snow
2017-12-08 14:24                   ` Max Reitz
2017-11-30 12:10           ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2017-12-07  0:38             ` John Snow
2017-12-07  9:39               ` Vladimir Sementsov-Ogievskiy
2017-12-09  0:57                 ` John Snow
2017-12-11  9:14                   ` Denis V. Lunev
2017-12-11 11:15                   ` Kevin Wolf
2017-12-11 12:18                     ` Vladimir Sementsov-Ogievskiy
2017-12-12 22:15                       ` John Snow
2017-12-11 18:40                     ` John Snow
2017-12-12 11:16                       ` Kevin Wolf
2017-11-20 16:00       ` Denis V. Lunev
2017-11-24 15:01         ` Vladimir Sementsov-Ogievskiy
2017-11-27 12:04           ` Kevin Wolf
2017-12-13  4:12 ` Fam Zheng
2017-12-19 16:07   ` Vladimir Sementsov-Ogievskiy
2017-12-20  1:06     ` John Snow
2017-12-20  8:05       ` Nikolay Shirokovskiy
2017-12-20  8:20       ` Vladimir Sementsov-Ogievskiy
2017-12-20 10:29         ` Kirill Korotaev
2017-12-26  7:07         ` Fam Zheng [this message]
2017-12-26  8:57           ` Vladimir Sementsov-Ogievskiy
2017-12-26  9:45             ` Fam Zheng

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=20171226070715.GF9418@lemon \
    --to=famz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=dev@acronis.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mnestratov@virtuozzo.com \
    --cc=mreitz@redhat.com \
    --cc=nshirokovskiy@virtuozzo.com \
    --cc=pbonzini@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).