From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=48472 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pu8TZ-0006mh-4r
	for qemu-devel@nongnu.org; Mon, 28 Feb 2011 14:09:46 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1Pu8TY-0003Ex-DQ
	for qemu-devel@nongnu.org; Mon, 28 Feb 2011 14:09:45 -0500
Received: from mx1.redhat.com ([209.132.183.28]:64830)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1Pu8TY-0003Es-27
	for qemu-devel@nongnu.org; Mon, 28 Feb 2011 14:09:44 -0500
Date: Mon, 28 Feb 2011 16:09:02 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [Qemu-devel] [patch 2/3] Add support for live block copy
Message-ID: <20110228190902.GA20993@amt.cnet>
References: <20110222170004.808373778@redhat.com>
	<20110222170115.710717278@redhat.com>
	<4D655AC6.3090503@codemonkey.ws> <20110226000214.GA30160@amt.cnet>
	<4D690408.1020404@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D690408.1020404@codemonkey.ws>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Jes.Sorensen@redhat.com, qemu-devel@nongnu.org, avi@redhat.com

On Sat, Feb 26, 2011 at 07:45:44AM -0600, Anthony Liguori wrote:
> >>>+- "commit_filename": target commit filename (json-string, optional)
> >>I think we should drop this.
> >Why? Sorry but this can't wait for non-config persistent storage. This
> >mistake was made in the past with irqchip for example, lets not repeat
> >it.
> >
> >Its OK to deprecate "commit_filename" in favour of its location in
> >non-config persistent storage.
> >
> >Its not the end of the world for a mgmt app to handle change (not saying
> >its not a good principle) such as this.
> 
> Even as a one off, it's not a very good solution to the problem.
> We'd be way better of just having nothing here than using the commit
> file.  What are the semantics of a half written file?  How does a
> management tool detect a half written file?

If the commit file contains the full commit message, it can be
considered valid. Otherwise, it should be considered invalid.

Stopping the guest and waiting for mgmt to issue a continue command is a
solution, but it has drawbacks introduced by reliance on mgmt app (what 
if mgmt app crashes, latency, etc). 

But it seems that it is preferred over a commit file. 

Addressing the other comments in the meantime, thanks for input.