On 10/17/2018 02:24 PM, Eric Blake wrote:
> On 10/2/18 6:02 PM, John Snow wrote:
>> based on: jsnow/bitmaps staging branch
>>
>> This series builds on a previous standalone patch and adjusts
>> the permission for all (or most) of the QMP bitmap commands.
>>
>> V4:
>> - Replace "in-use" with "in use"
>> - Replace "user_modifiable" version with "user_locked"
>> - Remove more usages of frozen-and-or-locked in NBD.
>>
>> John Snow (6):
>> block/dirty-bitmaps: add user_locked status checker
>> block/dirty-bitmaps: fix merge permissions
>> block/dirty-bitmaps: allow clear on disabled bitmaps
>> block/dirty-bitmaps: prohibit enable/disable on locked/frozen bitmaps
>> block/backup: prohibit backup from using in use bitmaps
>> nbd: forbid use of frozen bitmaps
>
> Just now noticing that our docs are slightly out of sync with these
> changes:
>
> # @DirtyBitmapStatus:
> #
> # An enumeration of possible states that a dirty bitmap can report to
> the user.
> #
> # @frozen: The bitmap is currently in-use by a backup operation or block
> job,
> # and is immutable.
> #
> # @disabled: The bitmap is currently in-use by an internal operation and is
> # read-only. It can still be deleted.
>
> This state is also reachable when using x-block-dirty-bitmap-disable,
> which is not an internal operation. We probably also ought to document
> that this state is a prereq to x-nbd-server-add-bitmap, since...
>
> #
> # @active: The bitmap is actively monitoring for new writes, and can be
> cleared,
> # deleted, or used for backup operations.
>
> ...active is not valid for that usage.
>
> #
> # @locked: The bitmap is currently in-use by some operation and can not be
> # cleared, deleted, or used for backup operations. (Since 2.12)
>
>
Ah, you're right. The rationale on disabled there is a bit wrong. I
think active is still correct, but the pull workflow has some extra
criteria.
I'll give a shot at touching this up.
--js
