From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRTj2-0001ZC-Q4 for qemu-devel@nongnu.org; Tue, 31 May 2011 14:31:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRTj0-0001Wn-UI for qemu-devel@nongnu.org; Tue, 31 May 2011 14:31:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRTj0-0001Wb-D8 for qemu-devel@nongnu.org; Tue, 31 May 2011 14:31:30 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4VHPD0V016840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 31 May 2011 13:25:26 -0400 Message-ID: <4DE51D18.9060309@redhat.com> Date: Tue, 31 May 2011 19:53:44 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20110523213115.164535428@amt.cnet> <20110523213411.003695437@amt.cnet> <4DE209C1.4080807@redhat.com> <20110531160636.GA9656@amt.cnet> <4DE51401.6040602@redhat.com> <20110531163858.GB9656@amt.cnet> In-Reply-To: <20110531163858.GB9656@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: kwolf@redhat.com, Jes.Sorensen@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org On 05/31/2011 07:38 PM, Marcelo Tosatti wrote: > > > > >Disadvantages: > > > > > >- Guest write performance is affected during copying (guest writes > > > compete with stream of writes from copy). > > > > Competes anyway with your background task? > > No because guest writes are to the source and copy writes are to > destination (which are potentially different disks or set of disks). Your copy task reads from the source disk and writes to the destination disk. A guest write doesn't touch the destination disk, but schedules a later write due to dirty tracking. In all, the total number of writes should be similar. Background copy is a more efficient since multiple writes to the same location are coalesced, but that's not very common (except perhaps for transaction logs). > > > > >- Unability to have the mirror functionality in a separate driver. > > > > Why? > > Because you need to handle the interaction between guest writes and > copy writes someplace which can be aware of both. > > For example, in-flight copy writes must be invalidated in the guest > write path. guest -> device -> mirror driver -> [ source disk, destination disk ] > > >> It would also remove the conflict with migration. > > > > > >There is no fundamental problem with migration, its simply unsupported > > >now. > > > > Why? > > Don't see the need for that, management can simply wait for livecopy to > finish or cancel livecopy and restart on destination after migration. They can do it, but I imagine it's pretty hard for them. > But yeah, it should be implemented sometime... > We should make an effort not to introduce interdependencies which make management's life harder. -- error compiling committee.c: too many arguments to function