| Message ID | 20190620010356.19164-2-jsnow@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | bitmaps: introduce 'bitmap' sync mode | expand |
On 20.06.19 03:03, John Snow wrote: > Depending on what a user is trying to accomplish, there might be a few > bitmap cleanup actions that occur when an operation is finished that > could be useful. > > I am proposing three: > - NEVER: The bitmap is never synchronized against what was copied. > - ALWAYS: The bitmap is always synchronized, even on failures. > - CONDITIONAL: The bitmap is synchronized only on success. > > The existing incremental backup modes use 'conditional' semantics, > so add just that one for right now. > > Signed-off-by: John Snow <jsnow@redhat.com> > --- > qapi/block-core.json | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/qapi/block-core.json b/qapi/block-core.json > index 0d43d4f37c..caf28a71a0 100644 > --- a/qapi/block-core.json > +++ b/qapi/block-core.json > @@ -1134,6 +1134,20 @@ > { 'enum': 'MirrorSyncMode', > 'data': ['top', 'full', 'none', 'incremental'] } > > +## > +# @BitmapSyncMode: > +# > +# An enumeration of possible behaviors for the synchronization of a bitmap > +# when used for data copy operations. > +# > +# @conditional: The bitmap is only synchronized when the operation is successul. *successful > +# This is useful for Incremental semantics. Hm, well. All bitmap modes are for incremental semantics, in some way or another. (“conditional” and “always” just automatically create point-in-time snapshots, in a sense, where “never” requires the user to manually do so.) So maybe something more concrete would be better? Like “This allows incremental use from one successful operation to the next, and restarting any operation on failure”? Max > +# > +# Since: 4.1 > +## > +{ 'enum': 'BitmapSyncMode', > + 'data': ['conditional'] } > + > ## > # @MirrorCopyMode: > # >
diff --git a/qapi/block-core.json b/qapi/block-core.json index 0d43d4f37c..caf28a71a0 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -1134,6 +1134,20 @@ { 'enum': 'MirrorSyncMode', 'data': ['top', 'full', 'none', 'incremental'] } +## +# @BitmapSyncMode: +# +# An enumeration of possible behaviors for the synchronization of a bitmap +# when used for data copy operations. +# +# @conditional: The bitmap is only synchronized when the operation is successul. +# This is useful for Incremental semantics. +# +# Since: 4.1 +## +{ 'enum': 'BitmapSyncMode', + 'data': ['conditional'] } + ## # @MirrorCopyMode: #
Depending on what a user is trying to accomplish, there might be a few bitmap cleanup actions that occur when an operation is finished that could be useful. I am proposing three: - NEVER: The bitmap is never synchronized against what was copied. - ALWAYS: The bitmap is always synchronized, even on failures. - CONDITIONAL: The bitmap is synchronized only on success. The existing incremental backup modes use 'conditional' semantics, so add just that one for right now. Signed-off-by: John Snow <jsnow@redhat.com> --- qapi/block-core.json | 14 ++++++++++++++ 1 file changed, 14 insertions(+)