Il 31/07/2012 14:17, Kevin Wolf ha scritto: >> No, that should be ok. Though I'm not sure if it's so useful to apply >> throttling on the target. It's more useful to throttle the source >> (making writes slower than reads will help the job's convergence) and >> copy at full steam to the target. > > But doesn't the rate limiting of the mirror already throttle the target?
Of course whatever you throttle (any of job, source, target) will have an effect on the other two as well. IMO, the target is perhaps the least useful to throttle. It is more interesting to play with the source, because that's guest visible. Slowing down the target, while letting the guest run at full speed is unlikely to help convergence of the job. On the other hand, the job and target speeds are really duplicates of each other, so the job speed is really just as useless. So it sounds like removing the job speed is a good idea. If needed, libvirt can implement it later with a named block device for the target + I/O throttling. > Which isn't too bad, because I think at least in the initial phase > you'll want to have both source and target throttled (later the target > is automatically throttled to the level of the source, except for bitmap > granularity artefacts). The target is always throttled to the level of the source and vice versa. The target can never be written faster than you read the source; and slowing down the target will keep buffers busy so you cannot read more from the source. Paolo