From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58738 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBPrG-0005c2-GQ for qemu-devel@nongnu.org; Thu, 28 Oct 2010 06:37:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBPrE-0000GQ-Lo for qemu-devel@nongnu.org; Thu, 28 Oct 2010 06:37:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBPrE-0000G3-FX for qemu-devel@nongnu.org; Thu, 28 Oct 2010 06:37:20 -0400 Message-ID: <4CC9527C.1000304@redhat.com> Date: Thu, 28 Oct 2010 12:37:48 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v3 5/5] qed: Consistency check support References: <1287759383-14114-1-git-send-email-stefanha@linux.vnet.ibm.com> <1287759383-14114-6-git-send-email-stefanha@linux.vnet.ibm.com> <4CC84AA4.2030701@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , Stefan Hajnoczi , Juan Quintela , qemu-devel@nongnu.org, Avi Kivity , Christoph Hellwig Am 28.10.2010 12:15, schrieb Stefan Hajnoczi: > On Wed, Oct 27, 2010 at 4:52 PM, Kevin Wolf wrote: >> 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 >> >> 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? > > You're right, migration is not supported. This is also true for the > other image formats which cache metadata in memory though. Is this still broken in upstream? This is a shame. I think the problem was that Anthony was opposed to reopening the image because we might lose it on that occasion? Instead of possibly crashing a VM in the worst case we regularly corrupt images now... *sigh* > I am actually looking into migration next together with Adam Litke who > has already started. We'll have to defer accessing the file until the > source has flushed/closed it. Sounds to me like an ugly workaround for the fundamental problem that the image file is opened twice at the same time. Ugly because it's not even in a central place, but must be done for each image format separately. Opening the file read-only first and reopening it read-write when the migration has completed would be much better. No image format driver would have to be changed for that. Kevin