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. Paolo
