Re: [libvirt] [PATCH] virsh: report 0-length active block-commit job status
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?