On 07/09/2014 03:24 PM, Paolo Bonzini wrote: > Il 07/07/2014 21:13, Eric Blake ha scritto: >> On 07/05/2014 11:47 AM, Max Reitz wrote: >>> Instead of taking the total length of the block device as the block >>> job's length, use the number of dirty sectors. The progress is now the >>> number of sectors mirrored to the target block device. Note that this >>> may result in the job's length increasing during operation, which is >>> however in fact desirable. >>> >>> Signed-off-by: Max Reitz <mre...@redhat.com> >>> --- >>> block/mirror.c | 34 ++++++++++++++++++++++------------ >>> 1 file changed, 22 insertions(+), 12 deletions(-) >> >> Reviewed-by: Eric Blake <ebl...@redhat.com> > > This is an API change... IIUC the length can become bigger than the > underlying device's size. Eric, how would libvirt expose this to > clients and what are the chances that they get confused?
Libvirt has already documented that a job size is unrelated to the block device size, that it is only an approximation to completion, and that the completion number may change during operation. The only hard and fast rule is that the job is finished when the two counters are equal. I recommended this change precisely because the new semantics are better than the old, including how libvirt exposes the numbers to the end user - if the end parameter continues to grow more than the current parameter, it is DESIRABLE to expose that as sign that the guest is dirtying pages fast enough to cause problems in converging the block job. http://libvirt.org/html/libvirt-libvirt.html#virDomainBlockJobInfo "The following fields provide an indication of block job progress. @cur indicates the current position and will be between 0 and @end. @end is the final cursor position for this operation and represents completion. To approximate progress, divide @cur by @end." -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature