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