From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S62ql-0003VB-Eq for qemu-devel@nongnu.org; Fri, 09 Mar 2012 11:39:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S62qc-00035l-Ao for qemu-devel@nongnu.org; Fri, 09 Mar 2012 11:39:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S62qc-00034H-2m for qemu-devel@nongnu.org; Fri, 09 Mar 2012 11:39:18 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q29GdGO3022170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Mar 2012 11:39:16 -0500 Message-ID: <4F5A3306.3010006@redhat.com> Date: Fri, 09 Mar 2012 17:42:46 +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> In-Reply-To: <4F58F286.6060209@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 08.03.2012 18:55, schrieb Avi Kivity: > On 03/08/2012 07:15 PM, Paolo Bonzini wrote: >> While the formats/protocols are free to implement a discard operation >> that does *not* zero the data, providing a common view to the guests is >> the only way to avoid configuration and migration nightmares. (We don't >> want the admin to manually set up discard_zeroes_data/discard_granularity!) >> >> This has a couple of drawbacks: >> >> 1) QEMU effectively will not try to use discard unless discard_zeroes_data >> is true. To do this we could add a flag such as BDRV_ALWAYS_DISCARD, >> which the device models could use if their discard_zeroes_data property is >> set to false. However, I haven't done this, estimating that no strictly >> positive integer could represent the number of people using it. >> >> 2) it may turn a thin-provisioning operation into a full preallocation, >> which is not nice. >> >> 3) it may cost memory for a bounce buffer that only needs to be filled >> with zeroes. >> >> 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. Kevin