[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bi
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bit |
Date: |
Thu, 28 Feb 2019 14:01:12 +0000 |
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
[Qemu-devel] [PATCH] dirty-bitmap: introduce inconsistent bitmaps, Vladimir Sementsov-Ogievskiy, 2019/02/25
[Qemu-devel] [PATCH v2 2/4] block/dirty-bitmap: add inconsistent status, John Snow, 2019/02/22
[Qemu-devel] [PATCH v2 3/4] block/dirty-bitmaps: add block_dirty_bitmap_check function, John Snow, 2019/02/22