From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHuYm-0002r1-MM for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:23:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHuYg-0003me-I2 for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:23:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHuYg-0003mY-8E for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:22:54 -0500 Date: Mon, 24 Feb 2014 13:22:47 +0100 From: Kevin Wolf Message-ID: <20140224122247.GH3775@dhcp-200-207.str.redhat.com> 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> <530B36D2.7040900@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530B36D2.7040900@redhat.com> 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: Paolo Bonzini Cc: Peter Lieven , Fam Zheng , qemu-devel@nongnu.org, stefanha@redhat.com Am 24.02.2014 um 13:10 hat Paolo Bonzini geschrieben: > 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). Hm, okay. So the intended behaviour for qcow2 is: - without MAY_UNMAP: Preallocate the cluster and set the zero flag so that its content isn't valid - with MAY_UNMAP: If the cluster is allocated, leave it allocated and set the zero flag; if it isn't, leave it unallocated and set the zero flag. > 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? Flushes are pretty expensive. If you only have many discards in a row and then many allocations in a row, it's probably okay. Mixing them so that every other write is a discard might well kill performance. Kevin