qemu-devel
[Top][All Lists]
Advanced

[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: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bit
Date: Thu, 28 Feb 2019 07:44:56 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]