diff options
author | Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> | 2020-03-11 13:29:57 +0300 |
---|---|---|
committer | Max Reitz <mreitz@redhat.com> | 2020-03-11 12:42:30 +0100 |
commit | d0ebeca14a585f352938062ef8ddde47fe4d39f9 (patch) | |
tree | 3c4fff3b2ca9373fbbf637497080fbcb91569009 /python | |
parent | 01fe1ca945345d3dc420d70c69488143dc0451b1 (diff) | |
download | qemu-d0ebeca14a585f352938062ef8ddde47fe4d39f9.zip qemu-d0ebeca14a585f352938062ef8ddde47fe4d39f9.tar.gz qemu-d0ebeca14a585f352938062ef8ddde47fe4d39f9.tar.bz2 |
block/block-copy: fix progress calculation
Assume we have two regions, A and B, and region B is in-flight now,
region A is not yet touched, but it is unallocated and should be
skipped.
Correspondingly, as progress we have
total = A + B
current = 0
If we reset unallocated region A and call progress_reset_callback,
it will calculate 0 bytes dirty in the bitmap and call
job_progress_set_remaining, which will set
total = current + 0 = 0 + 0 = 0
So, B bytes are actually removed from total accounting. When job
finishes we'll have
total = 0
current = B
, which doesn't sound good.
This is because we didn't considered in-flight bytes, actually when
calculating remaining, we should have set (in_flight + dirty_bytes)
as remaining, not only dirty_bytes.
To fix it, let's refactor progress calculation, moving it to block-copy
itself instead of fixing callback. And, of course, track in_flight
bytes count.
We still have to keep one callback, to maintain backup job bytes_read
calculation, but it will go on soon, when we turn the whole backup
process into one block_copy call.
Cc: qemu-stable@nongnu.org
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Message-Id: <20200311103004.7649-3-vsementsov@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'python')
0 files changed, 0 insertions, 0 deletions