From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ykqym-0003K4-TP for qemu-devel@nongnu.org; Wed, 22 Apr 2015 05:30:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ykqyj-00029p-NX for qemu-devel@nongnu.org; Wed, 22 Apr 2015 05:30:00 -0400 Date: Wed, 22 Apr 2015 10:29:53 +0100 From: Stefan Hajnoczi Message-ID: <20150422092953.GE6581@stefanha-thinkpad.redhat.com> References: <1428055280-12015-1-git-send-email-wency@cn.fujitsu.com> <1428055280-12015-2-git-send-email-wency@cn.fujitsu.com> <20150420153047.GB32653@stefanha-thinkpad.redhat.com> <5535A727.5080402@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CGDBiGfvSTbxKZlW" Content-Disposition: inline In-Reply-To: <5535A727.5080402@cn.fujitsu.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Fam Zheng , Lai Jiangshan , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , Max Reitz , Gonglei , Stefan Hajnoczi , Paolo Bonzini , Yang Hongyang , "Dr. David Alan Gilbert" , zhanghailiang --CGDBiGfvSTbxKZlW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 21, 2015 at 09:25:59AM +0800, Wen Congyang wrote: > On 04/20/2015 11:30 PM, Stefan Hajnoczi wrote: > > On Fri, Apr 03, 2015 at 06:01:07PM +0800, Wen Congyang wrote: > > One general question about the design: the Secondary host needs 3x > > storage space since it has the Secondary Disk, hidden-disk, and > > active-disk. Each image requires a certain amount of space depending on > > writes or COW operations. Is 3x the upper bound or is there a way to > > reduce the bound? >=20 > active disk and hidden disk are temp file. It will be maked empty in > bdrv_do_checkpoint(). Their format is qcow2 now, so it doesn't need too > many spaces if we do checkpoint periodically. A question related to checkpoints: both Primary and Secondary are active (running) in COLO. The Secondary will be slower since it performs extra work; disk I/O on the Secondary has a COW overhead. Does this force the Primary to wait for checkpoint commit so that the Secondary can catch up? I'm a little confused about that since the point of COLO is to avoid the overheads of microcheckpointing, but there still seems to be a checkpointing bottleneck for disk I/O-intensive applications. > >=20 > > The bound is important since large amounts of data become a bottleneck > > for writeout/commit operations. They could cause downtime if the guest > > is blocked until the entire Disk Buffer has been written to the > > Secondary Disk during failover, for example. >=20 > OK, I will test it. In my test, vm_stop() will take about 2-3 seconds if > I run filebench in the guest. Is there anyway to speed it up? Is it necessary to commit the active disk and hidden disk to the Secondary Disk on failover? Maybe the VM could continue executing immediately and run a block-commit job. The active disk and hidden disk files can be dropped once block-commit finishes. --CGDBiGfvSTbxKZlW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVN2oRAAoJEJykq7OBq3PIMjwH/28Yk5dWHXwqNxTpdbbefd7V V2NTpKmrrgBWa00HxrwjU87xKpBcOW4AAKWxFmeJOIxgZNWqjp1nF+ZE295Zl9xD GEWFGpaW0ttO4/PJQolrE2DGcYUFjX9tbwDl6nY+bcUvgVr1HTpPwGx0+dSP6a8h ro02z0tn+bS6+VhsrVHq7VJcptSiEHwXBAO+K7N9xZENg69iSZWEPibcfprjcpBm FeYk0UlBeoxC4/RsA+COQsYi/pjs0oUvh5+Rl4o0Qy+9WAeOxbb2Tgxu98j0p9v5 gR51ca5eVqlMaZup/mnObYyPWQ1zDon9Jqz2d1Rw88sNiJACISjyzMH0Fr77GgM= =Q/0n -----END PGP SIGNATURE----- --CGDBiGfvSTbxKZlW--