From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lm4me-0001W0-Hk
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:27:04 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lm4ma-0001Ua-U7
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:27:04 -0400
Received: from [199.232.76.173] (port=58169 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lm4ma-0001UU-Pq
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:27:00 -0400
Received: from mx2.redhat.com ([66.187.237.31]:36148)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <gleb@redhat.com>) id 1Lm4ma-0000Xc-D9
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:27:00 -0400
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2OBQxZH009438
	for <qemu-devel@nongnu.org>; Tue, 24 Mar 2009 07:26:59 -0400
Date: Tue, 24 Mar 2009 13:22:57 +0200
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 00/14] block (mostly qcow2) changes (v6)
Message-ID: <20090324112257.GD30294@redhat.com>
References: <1237322452-11337-1-git-send-email-uril@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1237322452-11337-1-git-send-email-uril@redhat.com>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org
Cc: Uri Lublin <uril@redhat.com>

On Tue, Mar 17, 2009 at 10:40:38PM +0200, Uri Lublin wrote:
> Changes from v5:
>    Patchset includes newly introduced qcow2 extensions.
>    Usage of such qcow2 extensions for keeping both backing format and 
>        highest-allocated-offset.
>    No scanning of qcow2 images upon open.
highest-allocated-offset is written to a disk only if block device was closed
properly, so this value can't actually be trusted to be accurate. How
important is to maintain it accurate? If it is important it should be
saved on disk as part of a metadata update and if it is not it can be
updated on a first guest write that requires new block allocation.

--
			Gleb.