From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S72zq-0005WF-Jb for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:00:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S72zo-0007aq-O4 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:00:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S72zo-0007af-Fc for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:00:56 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2CB0s1P031845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 07:00:54 -0400 Message-ID: <4F5DD83A.3080309@redhat.com> Date: Mon, 12 Mar 2012 12:04:26 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1331226917-6658-1-git-send-email-pbonzini@redhat.com> <1331226917-6658-8-git-send-email-pbonzini@redhat.com> <4F58F286.6060209@redhat.com> <4F5A3306.3010006@redhat.com> <4F5DD31C.20608@redhat.com> In-Reply-To: <4F5DD31C.20608@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 07/17] block: make high level discard operation always zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Paolo Bonzini , qemu-devel@nongnu.org Am 12.03.2012 11:42, schrieb Avi Kivity: > On 03/09/2012 06:42 PM, Kevin Wolf wrote: >>>> >>>> While (3) can be worked around, the only way around the other two, >>>> unfortunately, is support in the formats and protocols. We will still >>>> provide device options to opt out of this, but with raw and qed covered >>>> (+ qcow2 without backing file, and qcow3 in the future) it should not >>>> be too bad. >>> >>> Can't qcow2 with a backing file also be supported? Zero out the first >>> cluster, and remember it. The following discards can reuse this zero >>> cluster, as long as it hasn't been overwritten. >> >> qcow2 can't handle clusters that are referenced twice from the same L1 >> table. This would require a reverse lookup to adjust the QCOW_O_COPIED >> flags in the L2 tables containing the other references. > > Don't follow, sorry. What adjustment are you talking about? > > If it's a 1->0 transition, is it mandatory to adjust the flag? That is, > it it legal to have a refcount of exactly one, but have the flag clear? According to the spec it's illegal and qemu-img check will complain, too. In practice, I'm not entirely sure if it will cause real corruption or just unnecessary COWs. I believe it may be the latter. But it's not worth the trouble anyway when we can have a real zero flag in qcow3. Kevin