Re: [Qemu-devel] active block commit bug?

[Fam Zheng <famz@redhat.com>]

On Wed, 06/04 20:55, Eric Blake wrote:
> On 06/04/2014 08:09 PM, Fam Zheng wrote:
> 
> >> Sounds like we have an off-by-one condition if empty files behave
> >> differently from other files.  We ought to fix that bug (not that your
> >> normal guest will ever have a 0-length backing file, but this was what I
> >> was trying to use for libvirt's probing of whether active commit is
> >> supported)
> >>
> > 
> > Yes, agreed, this special case is only going to make management confused. I
> > will send a patch to fix this.
> 
> Thanks.
> 
> > 
> > Eric, is this a good way to probe the active commit? I was expecting full
> > instrospection of QMP could do it, but I don't know about the status of that
> > piece of work. Amos, any ideas?
> 
> Introspection already missed qemu 2.0 when active commit was added; and
> we're close enough to soft freeze for 2.1 that I'm guessing it will miss
> 2.1 as well :(
> 
> So yes, I'm experimenting with how to learn if active commit works by
> seeing what error message differences I can trigger with minimum effort;
> libvirt will cache what it learns so that it only has to ask once per
> qemu binary/timestamp, then let the user know up front whether active
> commit will work.  Since there are existing qemu versions that have
> active commit but not introspection, I'm stuck using this harder probe
> to avoid a false negative for those older qemu.  My other option is to
> just wait for introspection, or even something intermediate like Jeff's
> patch to make 'top' optional, and just declare qemu 2.0 active commit as
> not working - but since it is only the special case of a 0-size file
> (which is fairly unlikely for any real client use, and certainly
> something I can avoid in the libvirt probing), it feels a bit harsh to
> reject 2.0 just for this corner-case bug.
> 

Thanks, I'll keep in mind the feature probing necessity in the future.

Fam