From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lm540-0000z2-VL for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:45:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lm53v-0000xs-Jz for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:44:59 -0400 Received: from [199.232.76.173] (port=58691 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lm53v-0000xp-GI for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:44:55 -0400 Received: from mx2.redhat.com ([66.187.237.31]:41020) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lm53v-0002vw-25 for qemu-devel@nongnu.org; Tue, 24 Mar 2009 07:44:55 -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 n2OBirg9012337 for ; Tue, 24 Mar 2009 07:44:53 -0400 Message-ID: <49C8C7B1.1010406@redhat.com> Date: Tue, 24 Mar 2009 13:44:49 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/14] block (mostly qcow2) changes (v6) References: <1237322452-11337-1-git-send-email-uril@redhat.com> <20090324112257.GD30294@redhat.com> In-Reply-To: <20090324112257.GD30294@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Uri Lublin Gleb Natapov wrote: > 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. > Good catch. I suggest a different approach. Have a notification that triggers when a write past a certain offset occurs: (qemu) block_watermark_notify ide0-0 123564435343 ... time passes ... (qemu) #block watermark exceeded: ide0-0 127454566544 This is in addition to pausing the VM on write error. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.