From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=45270 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PB8Hl-0007JY-Is
	for qemu-devel@nongnu.org; Wed, 27 Oct 2010 11:51:39 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PB8Hf-0004Mk-QC
	for qemu-devel@nongnu.org; Wed, 27 Oct 2010 11:51:33 -0400
Received: from mx1.redhat.com ([209.132.183.28]:1948)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PB8Hf-0004MR-Jm
	for qemu-devel@nongnu.org; Wed, 27 Oct 2010 11:51:27 -0400
Message-ID: <4CC84AA4.2030701@redhat.com>
Date: Wed, 27 Oct 2010 17:52:04 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1287759383-14114-1-git-send-email-stefanha@linux.vnet.ibm.com>
	<1287759383-14114-6-git-send-email-stefanha@linux.vnet.ibm.com>
In-Reply-To: <1287759383-14114-6-git-send-email-stefanha@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH v3 5/5] qed: Consistency check support
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: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>

Am 22.10.2010 16:56, schrieb Stefan Hajnoczi:
> This patch adds support for the qemu-img check command.  It also
> introduces a dirty bit in the qed header to mark modified images as
> needing a check.  This bit is cleared when the image file is closed
> cleanly.
> 
> If an image file is opened and it has the dirty bit set, a consistency
> check will run and try to fix corrupted table offsets.  These
> corruptions may occur if there is power loss while an allocating write
> is performed.  Once the image is fixed it opens as normal again.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Hm, do I understand right that you fix the image and reset the dirty
flag in the header during bdrv_open? So how does this work with
migration, when the destination host opens the QED file before the
source closes it? Doesn't the destination destroy the image by "fixing" it?

And even if that wasn't the case, clearing the flag means that the
source might do new writes and thinks that the flag is still set. If the
source crashes now, we may need a consistency check, but the dirty flag
isn't set any more.

Am I missing some detail?

Kevin