Re: [Qemu-devel] [PATCH 4/5] backup: simplify non-dirty bits progress processing

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

On 10/12/2017 06:42 AM, Vladimir Sementsov-Ogievskiy wrote:

>> I'm not sure we actually need a new field... let's just say that the job
>> length is the number of bytes described by the incremental backup. Every
>> time we copy some, move offset forward. This would give a more
>> appropriately linear/accurate sense of the progress.
>>
>> I think we are allowed to do this as I think we promise that these
>> progress numbers mean essentially nothing...
> 
> I'm not sure, length is published field, it is available in libvirt.
> IMHO, If we change it semantics it should
> firstly break our iotests but what it will break for users is
> unpredictable..

Libvirt already documents that progress numbers do NOT have any specific
meaning other than a rough estimate of percentage complete, and that it
IS acceptable for the numbers to jump around or move non-linearly during
a job.  I see no problem with returning different numbers than
previously if it makes our estimation of progress look smoother; it is
not a semantics change by the definition we've given to the numbers, but
merely a quality-of-implementation improvement.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]