On 01/19/2015 03:01 PM, John Ferlan wrote:
>
Revisiting, now that the release is done.
>
> On 01/12/2015 05:54 PM, Eric Blake wrote:
>> At least with live block commit, it is possible to have a block
>> job that reports 0 status: namely, when the active image contains
>> no sectors that differ from the backing image it is being committed
>> into [1]. I'm not sure if that represents a qemu bug, but it leads
>> to weird virsh output where 'virsh blockjob $dom vda' has no output
>> during a no-op commit job. It appears that the special case for
>> a zero total was first introduced for migration, where it does sort
>> of make sense (when we do storage migration, the job is broken up
>> into two pieces where the first half of migrating storage has no
>> clue what the total length of the second phase will be, and where
>> qemu migration always reports a non-zero total length but only once
>> we complete the first phase to start actual migration), but it
>> doesn't seem to make sense for any of the block jobs.
>>
>> @@ -1678,10 +1678,6 @@ vshPrintJobProgress(const char *label, unsigned long long remaining,
>> {
>> int progress;
>>
>> - if (total == 0)
>> - /* migration has not been started */
>> - return;
>> -
>
> Would it be necessarily true that remaining was zero at this point?
I've never seen a case where qemu (and thus libvirt) reported remaining
> total.
> Because if it wasn't then, the else condition will divide by zero if
> total == 0... More than 1 caller to this function...
So I think we are safe in avoiding the divide by 0 potential. Of the
multiple callers, many are related to block jobs (where 0 status is
likely synonymous with no work to do) and the only caller I modified
(migration) is where 0 status means not yet started.
>
> Perhaps safer to say if "remaining == 0 || total == 0"?
>
> I was just reviewing Michal's patch from last week:
>
> http://www.redhat.com/archives/libvir-list/2015-January/msg00230.html
>
> where it seems a zero could imply some sort of failure. If you did the
> total == 0 check, then the && jobinfo.dataTotal isn't necessary... I
> would suppose that an error would mean we're 100% done...
>
I'm also debating whether qemu has a bug for reporting 0 (it would be
nicer if it always reserved 0 for not started, and non-zero for
completed) - but how would we tell the difference between a fixed and
broken qemu?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list