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