[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [RFC PATCH 2/2] block/dirty-bitmap: implement inconsist
From: |
John Snow |
Subject: |
Re: [Qemu-block] [RFC PATCH 2/2] block/dirty-bitmap: implement inconsistent bit |
Date: |
Mon, 18 Feb 2019 18:48:16 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
On 2/18/19 3:37 PM, Eric Blake wrote:
> On 2/18/19 12:13 PM, Vladimir Sementsov-Ogievskiy wrote:
>> 14.02.2019 2:36, John Snow wrote:
>>> Signed-off-by: John Snow <address@hidden>
>>> ---
>>> block/dirty-bitmap.c | 15 +++++++++++++
>>> block/qcow2-bitmap.c | 42 ++++++++++++++++++-----------------
>>> blockdev.c | 43 ++++++++++++++++++++++++++++++++++++
>>> include/block/dirty-bitmap.h | 1 +
>>> 4 files changed, 81 insertions(+), 20 deletions(-)
>
>>> +void bdrv_dirty_bitmap_add_inconsistent_hint(Error **errp)
>>> +{
>>> + error_append_hint(errp, "Try block-dirty-bitmap-clear to mark this "
>>> + "bitmap consistent again, or
>>> block-dirty-bitmap-remove "
>>> + "to delete it.");
>>
>> bitmaps created by libvirt (or somebody) are related to some checkpoint. And
>> their name is
>> probably (Eric?) related to this checkpoint too. So, clear will never make
>> them consistent..
>> Only clear :)
>>
>> So, I don't like idea of clearing in-use bitmaps.
>
> It's always possible to delete a bitmap and then create a new one by the
> same name, to get the same effect of clearing an in-use bitmap. So let's
> start simple and declare that the only valid operation on an
> inconsistent bitmap is deletion.
>
OK, from the viewpoint of checkpoints specifically, that's a convincing
argument against it for now.
I'll tighten this.
[Qemu-block] [RFC PATCH 1/2] block/dirty-bitmaps: add inconsistent bit, John Snow, 2019/02/13
Re: [Qemu-block] [RFC PATCH 0/2] bitmaps: add inconsistent bit, Vladimir Sementsov-Ogievskiy, 2019/02/18