From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=45350 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OoFxM-0004fM-FY
	for qemu-devel@nongnu.org; Wed, 25 Aug 2010 09:23:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OoFxK-0005Rq-BY
	for qemu-devel@nongnu.org; Wed, 25 Aug 2010 09:23:56 -0400
Received: from mx1.redhat.com ([209.132.183.28]:25768)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OoFxK-0005Rk-3z
	for qemu-devel@nongnu.org; Wed, 25 Aug 2010 09:23:54 -0400
Message-ID: <4C75195A.8050508@redhat.com>
Date: Wed, 25 Aug 2010 16:23:38 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1282646430-5777-1-git-send-email-kwolf@redhat.com>
	<4C73C2BF.8050300@codemonkey.ws> <4C73C622.7080808@redhat.com>
	<4C73C926.3010901@codemonkey.ws> <4C73C9CF.7090800@redhat.com>
	<4C73CAA9.2060104@codemonkey.ws> <4C73CB85.9010306@redhat.com>
	<4C73CBD6.7000900@codemonkey.ws> <4C73CCCB.6050704@redhat.com>
	<4C73CF8D.5060405@codemonkey.ws> <4C74C2F3.9050506@redhat.com>
	<4C7510C1.8080305@codemonkey.ws>
In-Reply-To: <4C7510C1.8080305@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use
 bdrv_(p)write_sync for metadata writes"
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: Kevin Wolf <kwolf@redhat.com>, stefanha@gmail.com, mjt@tls.msk.ru, qemu-devel@nongnu.org, hch@lst.de

  On 08/25/2010 03:46 PM, Anthony Liguori wrote:
>
> If we had another disk format that only supported growth and metadata 
> for a backing file, can you think of another failure scenario?

btw, only supporting growth is a step backwards.  Currently file-backed 
disks keep growing even the guest-used storage doesn't grow, since once 
we allocate something we never release it.  But eventually guests will 
start using TRIM or DISCARD or however it's called, and then we can 
expose it and reclaim unused blocks.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.