From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwBw0-0000T6-VY for qemu-devel@nongnu.org; Tue, 31 Jul 2012 08:52:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwBvu-0000xv-2G for qemu-devel@nongnu.org; Tue, 31 Jul 2012 08:52:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwBvt-0000xr-QN for qemu-devel@nongnu.org; Tue, 31 Jul 2012 08:52:17 -0400 Message-ID: <5017D4FB.7070000@redhat.com> Date: Tue, 31 Jul 2012 14:52:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1343127865-16608-1-git-send-email-pbonzini@redhat.com> <1343127865-16608-29-git-send-email-pbonzini@redhat.com> <5017A4DA.80602@redhat.com> <5017A680.8050305@redhat.com> <5017A98E.8000109@redhat.com> <5017AD19.8090709@redhat.com> <5017B293.8050808@redhat.com> <5017B8AA.1010109@redhat.com> <5017BDCB.5000505@redhat.com> <5017C092.3040403@redhat.com> <5017CCC6.3060603@redhat.com> In-Reply-To: <5017CCC6.3060603@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 28/47] qmp: add drive-mirror command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: jcody@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com 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