From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57033 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pulf6-0001sb-6v for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:00:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pulf5-0003bN-3z for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:00:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pulf4-0003b1-Qt for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:00:15 -0500 Message-ID: <4D6E3F57.8050804@redhat.com> Date: Wed, 02 Mar 2011 15:00:07 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy References: <20110222170004.808373778@redhat.com> <20110222210735.GA9372@amt.cnet> <4D64266A.3060106@codemonkey.ws> <20110222230935.GA11082@amt.cnet> <4D644343.4050800@codemonkey.ws> <4D65051A.6070707@redhat.com> <4D651B20.70405@codemonkey.ws> <4D652852.60505@redhat.com> <4D652F73.3000305@codemonkey.ws> <4D65324A.5080408@redhat.com> <4D65359E.3040008@codemonkey.ws> <4D65416D.8040803@redhat.com> <4D656B97.5030301@codemonkey.ws> <4D661CB8.6010305@redhat.com> <4D667287.9010005@codemonkey.ws> <4D6677BE.2030009@redhat.com> <4D669C46.40909@codemonkey.ws> <4D6A150B.8030205@redhat.com> <4D6A58E0.9020607@codemonkey.ws> <4D6A6E38.4030700@redhat.com> <4D6A8CC9.4090304@codemonkey.ws> <4D6B5EFA.8060106@redhat.com> <4D6B98FD.7020103@codemonkey.ws> <4D6BA16A.2020204@redhat.com> <4D6BDFA1.3000100@redhat.com> <4D6CB556.5060401@redhat.c! om> <4D6E3A65.7090502@codemonke! y.ws> In-Reply-To: <4D6E3A65.7090502@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jes.Sorensen@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Marcelo Tosatti On 03/02/2011 02:39 PM, Anthony Liguori wrote: > > Here is where your race is: > > 2. Management sends a switch command > > 3. QEMU receives switch command > > 4. QEMU stops doubling IO and switches to the destination > > 5. QEMU sends acknowledgement of switch command > > 6. Management receives acknowledge of switch command > > 7. Management changes internal state definition to reflect the new > destination > > If QEMU or the management tool crashes after step 4 and before step 6, > when the management tool restarts QEMU with the source image, data > loss will have occurred (and potentially corruption if a flush had > happened). No. After step 2, any qemu restart will be with the destination image. If the management tool restarts, it can query the state (or just re-issue the switch command, which is idempotent). > > This all boils down to the Two Generals Problem[1]. It's simply not > fixable without making one end reliable and that means that someone > needs to fsync() something *after* the switchover happens but before > the first write happens. That can be QEMU (Avi's RAID proposal and my > state file proposal) or it can be the management tool (if we introduce > synchronous events). The two problems are not equivalent. Once the management tool receives acknowledgement that the switch occurred, the protocol terminates. -- error compiling committee.c: too many arguments to function