From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHuNV-0001Bq-9P for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:11:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHuNP-0007xL-AA for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:11:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHuNP-0007xE-1A for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:11:15 -0500 Message-ID: <530B36D2.7040900@redhat.com> Date: Mon, 24 Feb 2014 13:10:58 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1393074022-32388-1-git-send-email-pl@kamp.de> <20140222164512.GC16767@T430.redhat.com> <530A479E.4070900@kamp.de> <20140224010150.GA6840@T430.redhat.com> <530B216C.5050902@redhat.com> <20140224113311.GA24100@T430.redhat.com> <530B323C.5050609@redhat.com> <20140224120712.GG3775@dhcp-200-207.str.redhat.com> In-Reply-To: <20140224120712.GG3775@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] block: optimize zero writes with bdrv_write_zeroes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Peter Lieven , Fam Zheng , qemu-devel@nongnu.org, stefanha@redhat.com Il 24/02/2014 13:07, Kevin Wolf ha scritto: >> > Yeah, that's why I wrote "or should be". Those are the intended >> > semantics of bdrv_co_write_zeroes without BDRV_REQ_MAY_UNMAP: always >> > allocate a cluster that will read as zeroes (allocating even if it >> > does not necessarily write the zeroes). > Which would mean that there is no way to say "give me zeroes, and do it > in the cheapest way possible". Because that would be to leave the > allocation status as it is and just toggle the zero bit. If bdrv_co_write_zeroes is SCSI's "WRITE SAME without UNMAP", then it must allocate. I think "give me zeroes and do it in the cheapest way possible" is BDRV_REQ_MAY_UNMAP (which *may* unmap but it doesn't have to). That said, the really expensive part of unmapping is probably re-allocating the clusters on subsequent writes. The unmap itself isn't that expensive (even if you have to flush the refcount blocks before the L2 tables), is it? Paolo