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
signature.asc
Description: OpenPGP digital signature
