From: Eric Blake <eblake@redhat.com>
To: John Snow <jsnow@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>
Cc: vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>,
"famz >> Fam Zheng" <famz@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"armbru >> Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 01/17] docs: incremental backup documentation
Date: Wed, 11 Mar 2015 08:43:03 -0600 [thread overview]
Message-ID: <55005477.7000006@redhat.com> (raw)
In-Reply-To: <55004EE9.8010302@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]
On 03/11/2015 08:19 AM, John Snow wrote:
>
>
> On 03/11/2015 09:43 AM, Stefan Hajnoczi wrote:
>> On Mon, Mar 02, 2015 at 06:19:47PM -0500, John Snow wrote:
>>> +## Bitmap Modes
>>> +
>>> +* A Bitmap can be "enabled" (tracking writes, the default) or
>>> "disabled"
>>> +(read-only, I/O is ignored.) This state is currently only changed
>>> internally
>>> +for the purposes of migration, and otherwise remains enabled.
>>
>> From a QMP API perspective this information is not relevant. The
>> documentation is clearer without the concept of enabled/disabled.
>>
>
> Hm ... I suppose; If you want all mention of this gone from user view, I
> should actually remove this status field from the query, too. It is
> entirely possible to have a state where the bitmap is not frozen, but it
> is disabled (migration, perhaps others in the future?) so I left the
> status visible to the user for now.
>
> libvirt et al could likely rely on the migration status to know not to
> manipulate bitmaps, but having that status information directly in the
> bitmap didn't bother me.
With a back-compat perspective, it's easier to hide the field now and
add it later if we discover that it would have been useful to expose,
than it is to expose it now and then have to support it forever even
though no one uses it. I'm not yet sure if libvirt can make use of
knowing whether a bitmap is frozen/disabled.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2015-03-11 14:43 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 23:19 [Qemu-devel] [PATCH v2 00/17] block: transactionless incremental backup series John Snow
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 01/17] docs: incremental backup documentation John Snow
2015-03-03 15:28 ` Max Reitz
2015-03-11 13:43 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-03-11 14:19 ` John Snow
2015-03-11 14:43 ` Eric Blake [this message]
2015-03-11 14:45 ` John Snow
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 02/17] qapi: Add optional field "name" to block dirty bitmap John Snow
2015-03-11 15:34 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 03/17] qmp: Ensure consistent granularity type John Snow
2015-03-11 15:34 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 04/17] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove John Snow
2015-03-11 13:58 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-03-11 14:23 ` John Snow
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 05/17] block: Introduce bdrv_dirty_bitmap_granularity() John Snow
2015-03-11 15:34 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 06/17] hbitmap: add hbitmap_merge John Snow
2015-03-11 15:43 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 07/17] block: Add bitmap disabled status John Snow
2015-03-11 16:34 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 08/17] block: Add bitmap successors John Snow
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 09/17] qmp: Add support of "dirty-bitmap" sync mode for drive-backup John Snow
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 10/17] qmp: add block-dirty-bitmap-clear John Snow
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 11/17] qmp: Add dirty bitmap status fields in query-block John Snow
2015-03-11 16:54 ` Stefan Hajnoczi
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 12/17] block: add BdrvDirtyBitmap documentation John Snow
2015-03-02 23:19 ` [Qemu-devel] [PATCH v2 13/17] block: Ensure consistent bitmap function prototypes John Snow
2015-03-02 23:20 ` [Qemu-devel] [PATCH v2 14/17] block: Resize bitmaps on bdrv_truncate John Snow
2015-03-03 15:29 ` Max Reitz
2015-03-03 16:02 ` Max Reitz
2015-03-03 21:24 ` John Snow
2015-03-03 21:27 ` Max Reitz
2015-03-03 22:48 ` John Snow
2015-03-04 13:54 ` Max Reitz
2015-03-11 16:18 ` Stefan Hajnoczi
2015-03-11 17:04 ` John Snow
2015-03-02 23:20 ` [Qemu-devel] [PATCH v2 15/17] iotests: add invalid input incremental backup tests John Snow
2015-03-02 23:20 ` [Qemu-devel] [PATCH v2 16/17] iotests: add simple incremental backup case John Snow
2015-03-02 23:20 ` [Qemu-devel] [PATCH v2 17/17] iotests: add incremental backup failure recovery test John Snow
2015-03-03 15:26 ` [Qemu-devel] [PATCH v2 00/17] block: transactionless incremental backup series Max Reitz
2015-03-11 16:57 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
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=55005477.7000006@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=famz@redhat.com \
--cc=jsnow@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=vsementsov@parallels.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).