[libvirt] [PATCH] virsh: report 0-length active block-commit job status

[John Ferlan]

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?
>