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

[Vladimir Sementsov-Ogievskiy]

28.02.2019 16:44, Eric Blake wrote:
> 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).

Okay

> 
>>
>> 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.
> 

Agree

-- 
Best regards,
Vladimir