Re: [Qemu-devel] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bit

[Eric Blake <eblake@redhat.com>]

On 2/28/19 4:13 AM, Vladimir Sementsov-Ogievskiy wrote:

>>>>> +++ b/qapi/block-core.json
>>>>> @@ -470,12 +470,16 @@
>>>>>    # @persistent: true if the bitmap will eventually be flushed to persistent
>>>>>    #              storage (since 4.0)
>>>
>>> so, bitmap can't be inconsistent and persistent, as we don't want to flush
>>> inconsistent bitmaps...
>>>
>>
>> I think ideally I'd just change this phrasing to say something like
>> "true if the bitmap is stored on-disk, or is scheduled to be flushed to
>> disk."
> 
> And such wording leads to immediate question: why it could be stored on disk but
> _not_ scheduled to be flushed..
> 
> So if you want, more honest is something like "true if bitmap will be flushed to
> storage or if it is @inconsistent (read ahead)." but it's not looking nice...
> 
> May be something like this?
> 
> true if bitmap is marked to be flushed to persistent storage. Bitmap may or may not
> already persist in the storage. Also true if bitmap persist in the storage but
> considered inconsistent, in which case it will not be flushed and only may be removed,
> look at @inconsistent field description.

Too long. As @inconsistent is rare, I'd be happy with just:

@persistent: true if the bitmap is marked for association with
persistent storage

which covers both future flushes (for a bitmap that is not yet on disk,
but will get there later) and prior inconsistent images (where we
learned that it was inconsistent because of its existing associate with
persistent storage).

> 
> Another thing: what about migration? I don't think we are going to teach migration protocol
> to migrate them. So, migration is a way to get rid of inconsistent bitmaps? Or what? Or
> we should restrict migration, if there are any inconsistent bitmap, to force user to remove
> them first?

A conservative approach is to start by treating an inconsistent bitmap
as a migration blocker, and could be relaxed later if someone has an
argument for why making migration a backdoor for deletion of
inconsistent bitmaps is a good thing.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org