[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 10/11] block/backup: support bitmap sync mode
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v2 10/11] block/backup: support bitmap sync modes for non-bitmap backups |
Date: |
Tue, 16 Jul 2019 07:18:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
John Snow <address@hidden> writes:
> Accept bitmaps and sync policies for the other backup modes.
> This allows us to do things like create a bitmap synced to a full backup
> without a transaction, or start a resumable backup process.
>
> Some combinations don't make sense, though:
>
> - NEVER policy combined with any non-BITMAP mode doesn't do anything,
> because the bitmap isn't used for input or output.
> It's harmless, but is almost certainly never what the user wanted.
>
> - sync=NONE is more questionable. It can't use on-success because this
> job never completes with success anyway, and the resulting artifact
> of 'always' is suspect: because we start with a full bitmap and only
> copy out segments that get written to, the final output bitmap will
> always be ... a fully set bitmap.
>
> Maybe there's contexts in which bitmaps make sense for sync=none,
> but not without more severe changes to the current job, and omitting
> it here doesn't prevent us from adding it later.
>
> Signed-off-by: John Snow <address@hidden>
> ---
[...]
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 5a578806c5..099e4f37b2 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1352,13 +1352,15 @@
> # @speed: the maximum speed, in bytes per second. The default is 0,
> # for unlimited.
> #
> -# @bitmap: the name of a dirty bitmap if sync is "bitmap" or "incremental".
> +# @bitmap: The name of a dirty bitmap to use.
> # Must be present if sync is "bitmap" or "incremental".
> +# Can be present if sync is "full" or "top".
> # Must not be present otherwise.
> # (Since 2.4 (drive-backup), 3.1 (blockdev-backup))
> #
> # @bitmap-mode: Specifies the type of data the bitmap should contain after
> -# the operation concludes. Must be present if sync is "bitmap".
> +# the operation concludes.
> +# Must be present if a bitmap was provided,
> # Must NOT be present otherwise. (Since 4.2)
> #
> # @compress: true to compress data, if the target format supports it.
Do you expect management applications will want to know about the
presence of this patch?
- Re: [Qemu-devel] [PATCH v2 02/11] iotests/257: add EmulatedBitmap class, (continued)
- [Qemu-devel] [PATCH v2 07/11] block/backup: centralize copy_bitmap initialization, John Snow, 2019/07/15
- [Qemu-devel] [PATCH v2 08/11] block/backup: add backup_is_cluster_allocated, John Snow, 2019/07/15
- [Qemu-devel] [PATCH v2 05/11] iotests/257: test API failures, John Snow, 2019/07/15
- [Qemu-devel] [PATCH v2 06/11] block/backup: improve sync=bitmap work estimates, John Snow, 2019/07/15
- [Qemu-devel] [PATCH v2 10/11] block/backup: support bitmap sync modes for non-bitmap backups, John Snow, 2019/07/15
- [Qemu-devel] [PATCH v2 09/11] block/backup: teach TOP to never copy unallocated regions, John Snow, 2019/07/15
[Qemu-devel] [PATCH v2 03/11] iotests/257: Refactor backup helpers, John Snow, 2019/07/15
[Qemu-devel] [PATCH v2 11/11] iotests/257: test traditional sync modes, John Snow, 2019/07/15