From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHuGd-0000HP-CT for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:04:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHuGX-000541-DB for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:04:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHuGW-00051f-TT for qemu-devel@nongnu.org; Mon, 24 Feb 2014 07:04:09 -0500 Date: Mon, 24 Feb 2014 20:04:13 +0800 From: Fam Zheng Message-ID: <20140224120413.GB24100@T430.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530B323C.5050609@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: kwolf@redhat.com, Peter Lieven , qemu-devel@nongnu.org, stefanha@redhat.com On Mon, 02/24 12:51, Paolo Bonzini wrote: > Il 24/02/2014 12:33, Fam Zheng ha scritto: > >> This is (or should be) bdrv_co_write_zeroes without BDRV_REQ_MAY_UNMAP. > > > >But IIUC bdrv_co_write_zeroes without BDRV_REQ_MAY_UNMAP doesn't require > >cluster allocation if it's allocated yet, which is a bit different. > > 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). > > For legacy reasons it may not be exactly what is implemented. I asked Kevin > a couple of weeks ago and he sent a patch, but even he wasn't sure of what > qcow2 was doing util he looked at the code. :) > I see. I could only tell in VMDK cluster doesn't have this "mapped and zeroed" state, so maybe we need some flexibility here and reduce assumption. Fam