On 08/01/2014 02:18 PM, Max Reitz wrote:
>>> + if (status_cb) {
>>> + status_cb(bs, *visited_l1_entries << (s->l2_bits +
>>> s->cluster_bits),
>>> + l1_entries << (s->l2_bits + s->cluster_bits));
>> Shifting is a multiplication so it keep proportionality intact.
>> So do we really need these shifts ?
>
> As of patch 1, the variables are defined as "offset" and "working_size"
> which I meant to be byte ranges. We could indeed leave the unit for
> BlockDriverAmendStatusCB's parameters undefined (and leave it up to the
> block driver, only specifying that offset / working_size has to be the
> progress ratio), but then we could just as well just give a floating
> point percentage to that function.As it is, block jobs are already documented as merely exposing completion percentage, and NOT tied to the size of the underlying block device. Your own pending patch is proof of this: https://lists.gnu.org/archive/html/qemu-devel/2014-07/msg00960.html When doing drive-mirror, we WANT to have the total size grow according to how many dirty blocks are encountered through each pass, and the current offset grow in rough proportion to how fast we are converging to a mirrored state (or even having the percentage go backwards, when we are diverging from too much I/O pressure, as a sign that some throttling is needed). Artificially trying to constrain that progress reporting to the size in bytes of the block device does not help matters. > > Bytes as a unit seemed safe to me, however, since all of qemu's code > assumes byte ranges to always fit in int64_t; and the reason I preferred > them over a percentage is that block jobs use bytes as well. > > A real reason not to use bytes would be that some driver is unable to > give a "byte" representation of its workload during the amend progress; > however, this seems unlikely to me (every large workload which should be > part of the progress report should be somehow representable as bytes). I don't think we can promise anything more than two relative numbers, with no bearing on what they are measuring under the hood, so scaling both numbers just to produce progress output buys nothing. There may eventually be a device where we can't report progress in any more granularity than 0 (still working) or 1 (done). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
