On Tue, Apr 17, 2012 at 8:53 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 17/04/2012 04:50, Eric Blake ha scritto: >> Libvirt found out that we have a pretty nasty data race between >> block-stream and block-job-set-speed. If a user wants to throttle a >> job, they cannot request the throttling until after the job has been >> started (thanks to the DeviceNotActive error of block-job-set-speed), >> but by the time you actually get a chance to throttle the job, you have >> no idea how much data transpired between the job start and the >> throttling request. migrate_set_speed does not have this issue, since >> it can be issued _prior_ to the migration. >> >> Is there any way we can add an optional parameter to 'block-stream' (in >> the tree now) and 'drive-mirror' (in Paolo's pending patch series) to >> set the speed as part of starting the job, or to atomically fail with >> NotSupported if throttling cannot be managed, rather than having a race >> window before getting a chance to call block-job-set-speed? Now's the >> time to do it, since 'block-stream' is new to qemu 1.1. > > The NotSupported error from block-job-set-speed is really an > out-of-range error, and we should report it as such... > > I think that rather than adding lots of arguments, two better choices > are: 1) cancel the job if set-speed fails (for some definition of > better); 2) let block-job-set-speed work before starting a job, like you > said migration does.
I think it's cleanest to support block-job-set-speed even when no job is running. The speed will be used as the default value when a job is started. This poses the question of what happens if the job does not do throttling or cannot support the value for some reason - does creation fail until block-job-set-speed is set to 0 or a valid value again, or do we allow it but silently perform no throttling? Stefan
