From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFSUW-0000Hc-UY for qemu-devel@nongnu.org; Thu, 28 Apr 2011 10:46:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFSUV-0001GI-QP for qemu-devel@nongnu.org; Thu, 28 Apr 2011 10:46:52 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:46806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFSUV-0001G9-Nq for qemu-devel@nongnu.org; Thu, 28 Apr 2011 10:46:51 -0400 Received: by ywl41 with SMTP id 41so1195017ywl.4 for ; Thu, 28 Apr 2011 07:46:51 -0700 (PDT) Message-ID: <4DB97DD7.4060001@codemonkey.ws> Date: Thu, 28 Apr 2011 09:46:47 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1303136821-13333-1-git-send-email-Jes.Sorensen@redhat.com> <1303136821-13333-2-git-send-email-Jes.Sorensen@redhat.com> <20110427120520.74e348d9@doriath> <4DB97B55.7030202@codemonkey.ws> <4DB97BCA.4000604@redhat.com> In-Reply-To: <4DB97BCA.4000604@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: kwolf@redhat.com, Luiz Capitulino , Markus Armbruster , qemu-devel@nongnu.org On 04/28/2011 09:38 AM, Jes Sorensen wrote: > > Sorry but this is utterly bogus. > > The snapshot support as is works fine, and the command is in the > monitor. We should expose it in QMP as well. It went in for the monitor because it was considered an imperfect command so we held up the QMP side because we wanted a better interface. The current command does: 1) Create new image backing to current image 2) Flush outstanding I/O to old image 3) Close current image 4) Reopen newly created image 5) Go Operations (1) and (2) are very synchronous operations. (4) can be too. We really should have a bdrv_aio_snapshot() function that implements the logic for at least (2) in an asynchronous fashion. That sort of interface is going to affect how we expose things in QMP. As from a QMP perspective, we're going to do something like: a) start snapshot b) query snapshot progress c) receive notification of snapshot completion d) flip over image And of course, this needs to be carefully thought through for race conditions. In the current command, what happens if you get a crash between (2) and (3)? There's no way for the management tools to know that we didn't finish flushing writes. How does the management tool know that (1) didn't fail mid way through resulting in a corrupted image? Regards, Anthony Liguori