Re: [Qemu-devel] [Qemu-block] [PATCH v2 01/17] docs: incremental backup documentation

[John Snow]

On 03/11/2015 10:43 AM, Eric Blake wrote:
> On 03/11/2015 08:19 AM, John Snow wrote:
> > On 03/11/2015 09:43 AM, Stefan Hajnoczi wrote:
> > > On Mon, Mar 02, 2015 at 06:19:47PM -0500, John Snow wrote:
> > > > +## Bitmap Modes
> > > > +
> > > > +* A Bitmap can be "enabled" (tracking writes, the default) or
> > > > "disabled"
> > > > +(read-only, I/O is ignored.) This state is currently only changed
> > > > internally
> > > > +for the purposes of migration, and otherwise remains enabled.
> > >
> > >   From a QMP API perspective this information is not relevant.  The
> > > documentation is clearer without the concept of enabled/disabled.
> >
> > Hm ... I suppose; If you want all mention of this gone from user view, I
> > should actually remove this status field from the query, too. It is
> > entirely possible to have a state where the bitmap is not frozen, but it
> > is disabled (migration, perhaps others in the future?) so I left the
> > status visible to the user for now.
> >
> > libvirt et al could likely rely on the migration status to know not to
> > manipulate bitmaps, but having that status information directly in the
> > bitmap didn't bother me.
>
> With a back-compat perspective, it's easier to hide the field now and
> add it later if we discover that it would have been useful to expose,
> than it is to expose it now and then have to support it forever even
> though no one uses it.  I'm not yet sure if libvirt can make use of
> knowing whether a bitmap is frozen/disabled.

Makes sense. I suspect I will leave the frozen status there, though, 
because applying an operation to a frozen bitmap WILL result in an 
error, and it would be nice to be able to avoid that scenario instead of 
it being a hidden status that sometimes fails your commands.

Granted, it is only currently in this status while it is being USED for 
a job, so it may not be mechanically useful...