On 12/12/2012 06:46 AM, Paolo Bonzini wrote: > This makes sense when the next commit starts using the extra buffer space > to perform many I/O operations asynchronously. > > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > block/mirror.c | 6 +++--- > block_int.h | 5 +++-- > blockdev.c | 9 ++++++++- > hmp.c | 2 +- > qapi-schema.json | 5 ++++- > qmp-commands.hx | 4 +++- > tests/qemu-iotests/041 | 31 +++++++++++++++++++++++++++++++ > 7 files changed, 53 insertions(+), 9 deletions(-) >
> @@ -447,7 +447,7 @@ void mirror_start(BlockDriverState *bs, BlockDriverState > *target, > s->target = target; > s->mode = mode; > s->granularity = granularity; > - s->buf_size = granularity; > + s->buf_size = MAX(buf_size, granularity); So you silently clamp the buffer size if the user gives something larger than granularity. > +++ b/qapi-schema.json > @@ -1641,6 +1641,9 @@ > # are smaller than that, else the cluster size. Must be a > # power of 2 between 512 and 64M. > # > +# @buf-size: #optional maximum amount of data in flight from source to > +# target. Mention that it was added in 1.4. Also, is it worth mentioning reasonable bounds (such as granularity), and whether it must be a power of two? > - "granularity": granularity of the dirty bitmap (json-int, optional) > +- "buf_size": maximum amount of data in flight from source to target > + (json-int, default 10M) Oh, so unlike granularity, this one does NOT have to be a power of 2. But why is the default 10M if you clamp it to granularity, which defaults to 64k? (and again, something else I have to figure out how to expose from libvirt) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
