All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: qemu-devel@nongnu.org,  qemu-block@nongnu.org,
	 eblake@redhat.com, hreitz@redhat.com,  kwolf@redhat.com,
	 vsementsov@yandex-team.ru, jsnow@redhat.com,
	 f.gruenbichler@proxmox.com,  t.lamprecht@proxmox.com,
	mahaocong@didichuxing.com
Subject: Re: [RFC 1/4] drive-mirror: add support for sync=bitmap mode=never
Date: Wed, 21 Feb 2024 07:55:01 +0100	[thread overview]
Message-ID: <87il2i1f3u.fsf@pond.sub.org> (raw)
In-Reply-To: <20240216105513.309901-2-f.ebner@proxmox.com> (Fiona Ebner's message of "Fri, 16 Feb 2024 11:55:10 +0100")

Fiona Ebner <f.ebner@proxmox.com> writes:

> From: John Snow <jsnow@redhat.com>
>
> This patch adds support for the "BITMAP" sync mode to drive-mirror and
> blockdev-mirror. It adds support only for the BitmapSyncMode "never,"
> because it's the simplest mode.
>
> This mode simply uses a user-provided bitmap as an initial copy
> manifest, and then does not clear any bits in the bitmap at the
> conclusion of the operation.
>
> Any new writes dirtied during the operation are copied out, in contrast
> to backup. Note that whether these writes are reflected in the bitmap
> at the conclusion of the operation depends on whether that bitmap is
> actually recording!
>
> This patch was originally based on one by Ma Haocong, but it has since
> been modified pretty heavily.
>
> Suggested-by: Ma Haocong <mahaocong@didichuxing.com>
> Signed-off-by: Ma Haocong <mahaocong@didichuxing.com>
> Signed-off-by: John Snow <jsnow@redhat.com>
> [FG: switch to bdrv_dirty_bitmap_merge_internal]
> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> [FE: rebase for 9.0
>      update version and formatting in QAPI]
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>

[...]

> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index ab5a93a966..ac05483958 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -2181,6 +2181,15 @@
>  #     destination (all the disk, only the sectors allocated in the
>  #     topmost image, or only new I/O).
>  #
> +# @bitmap: The name of a bitmap to use for sync=bitmap mode.  This
> +#     argument must be present for bitmap mode and absent otherwise.
> +#     The bitmap's granularity is used instead of @granularity.
> +#     (Since 9.0).

What happens when the user specifies @granularity anyway?  Error or
silently ignored?

> +#
> +# @bitmap-mode: Specifies the type of data the bitmap should contain
> +#     after the operation concludes.  Must be present if sync is
> +#     "bitmap".  Must NOT be present otherwise.  (Since 9.0)

Members that must be present when and only when some enum member has a
certain value should perhaps be in a union branch.  Perhaps the block
maintainers have an opinion here.

> +#
>  # @granularity: granularity of the dirty bitmap, default is 64K if the
>  #     image format doesn't have clusters, 4K if the clusters are
>  #     smaller than that, else the cluster size.  Must be a power of 2
> @@ -2223,7 +2232,9 @@
>  { 'struct': 'DriveMirror',
>    'data': { '*job-id': 'str', 'device': 'str', 'target': 'str',
>              '*format': 'str', '*node-name': 'str', '*replaces': 'str',
> -            'sync': 'MirrorSyncMode', '*mode': 'NewImageMode',
> +            'sync': 'MirrorSyncMode', '*bitmap': 'str',
> +            '*bitmap-mode': 'BitmapSyncMode',
> +            '*mode': 'NewImageMode',
>              '*speed': 'int', '*granularity': 'uint32',
>              '*buf-size': 'int', '*on-source-error': 'BlockdevOnError',
>              '*on-target-error': 'BlockdevOnError',
> @@ -2507,6 +2518,15 @@
>  #     destination (all the disk, only the sectors allocated in the
>  #     topmost image, or only new I/O).
>  #
> +# @bitmap: The name of a bitmap to use for sync=bitmap mode.  This
> +#     argument must be present for bitmap mode and absent otherwise.
> +#     The bitmap's granularity is used instead of @granularity.
> +#     (Since 9.0).
> +#
> +# @bitmap-mode: Specifies the type of data the bitmap should contain
> +#     after the operation concludes.  Must be present if sync is
> +#     "bitmap".  Must NOT be present otherwise.  (Since 9.0)
> +#
>  # @granularity: granularity of the dirty bitmap, default is 64K if the
>  #     image format doesn't have clusters, 4K if the clusters are
>  #     smaller than that, else the cluster size.  Must be a power of 2
> @@ -2557,7 +2577,8 @@
>  { 'command': 'blockdev-mirror',
>    'data': { '*job-id': 'str', 'device': 'str', 'target': 'str',
>              '*replaces': 'str',
> -            'sync': 'MirrorSyncMode',
> +            'sync': 'MirrorSyncMode', '*bitmap': 'str',
> +            '*bitmap-mode': 'BitmapSyncMode',
>              '*speed': 'int', '*granularity': 'uint32',
>              '*buf-size': 'int', '*on-source-error': 'BlockdevOnError',
>              '*on-target-error': 'BlockdevOnError',

[...]



  reply	other threads:[~2024-02-21  6:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16 10:55 [RFC 0/4] mirror: implement incremental and bitmap modes Fiona Ebner
2024-02-16 10:55 ` [RFC 1/4] drive-mirror: add support for sync=bitmap mode=never Fiona Ebner
2024-02-21  6:55   ` Markus Armbruster [this message]
2024-02-21  9:21     ` Fiona Ebner
2024-02-16 10:55 ` [RFC 2/4] drive-mirror: add support for conditional and always bitmap sync modes Fiona Ebner
2024-02-16 10:55 ` [RFC 3/4] mirror: move some checks to qmp Fiona Ebner
2024-02-16 10:55 ` [RFC 4/4] iotests: add test for bitmap mirror Fiona Ebner
2024-02-28 16:00 ` [RFC 0/4] mirror: implement incremental and bitmap modes Vladimir Sementsov-Ogievskiy
2024-02-28 16:06   ` Vladimir Sementsov-Ogievskiy
2024-02-29 10:11     ` Fiona Ebner
2024-02-29 11:48       ` Vladimir Sementsov-Ogievskiy
2024-02-29 12:47         ` Fiona Ebner
2024-03-06 13:44           ` Fiona Ebner
2024-03-07  9:20             ` Vladimir Sementsov-Ogievskiy
2024-02-28 16:24 ` Vladimir Sementsov-Ogievskiy
2024-02-29 10:41   ` Fiona Ebner
2024-02-29 12:00     ` Vladimir Sementsov-Ogievskiy
2024-02-29 14:50       ` Fiona Ebner
2024-03-01 14:14         ` Vladimir Sementsov-Ogievskiy
2024-03-01 14:52           ` Fiona Ebner
2024-03-01 15:02             ` Vladimir Sementsov-Ogievskiy
2024-03-01 15:14               ` Fiona Ebner
2024-03-01 15:46                 ` Vladimir Sementsov-Ogievskiy
2024-03-04  7:50                   ` Fiona Ebner
2024-03-04  9:02     ` Fabian Grünbichler

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=87il2i1f3u.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=f.ebner@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mahaocong@didichuxing.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=t.lamprecht@proxmox.com \
    --cc=vsementsov@yandex-team.ru \
    /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.