On 11/02/2015 04:28 PM, John Snow wrote: > The mirror job doesn't update its total length until > it has already started running, so we should translate > a zero-length job-len as meaning 0%. > > Otherwise, we may get divide-by-zero faults. > > Signed-off-by: John Snow <js...@redhat.com> > --- > qemu-img.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-)
And indeed, this has tripped up libvirt in the past :) My only concern is what if you truly have a 0-length job? For example, when doing two block-stream commands with identical arguments in a row, the second block-stream has no work to do, but can complete instantly. Will this result in such a job never reporting 100% complete? If so, that's bad. If you can answer my concerns that we don't have a design bug, then the code changes look correct, and you can add: Reviewed-by: Eric Blake <ebl...@redhat.com> > > diff --git a/qemu-img.c b/qemu-img.c > index 3025776..38b4888 100644 > --- a/qemu-img.c > +++ b/qemu-img.c > @@ -656,7 +656,8 @@ static void run_block_job(BlockJob *job, Error **errp) > > do { > aio_poll(aio_context, true); > - qemu_progress_print((float)job->offset / job->len * 100.f, 0); > + qemu_progress_print(job->len ? > + ((float)job->offset / job->len * 100.f) : 0.00, > 0); Also, note that this promotes to double rather than float; maybe you want to use 0.f instead of 0.00 to keep the ternary as a float? But it shouldn't make a difference in practice. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature