On 01/27/2015 12:48 PM, Eric Blake wrote:
> 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.
>
What about the following?
- int progress;
-
- if (total == 0)
- /* migration has not been started */
- return;
+ int progress = 0;
if (remaining == 0) {
/* migration has completed */
progress = 100;
- } else {
+ } else if (remaining > 0) {
That way if this is called by "others" which use "... info.end -
info.cur, info.end);", we avoid the chance that info.end == 0 and
there's a divide by zero. The remaining == 0 still means we're done,
the remaining < 0 means perhaps we haven't started (no progress).
The only question I'd have is how much of an infinite loop this could be
if total never got > 0...
John
>>
>> 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?
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list