From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHjvf-0004kV-IN for qemu-devel@nongnu.org; Sun, 23 Feb 2014 20:02:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHjva-0007Y9-L9 for qemu-devel@nongnu.org; Sun, 23 Feb 2014 20:01:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHjva-0007Y4-Do for qemu-devel@nongnu.org; Sun, 23 Feb 2014 20:01:50 -0500 Date: Mon, 24 Feb 2014 09:01:50 +0800 From: Fam Zheng Message-ID: <20140224010150.GA6840@T430.redhat.com> References: <1393074022-32388-1-git-send-email-pl@kamp.de> <20140222164512.GC16767@T430.redhat.com> <530A479E.4070900@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530A479E.4070900@kamp.de> 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: Peter Lieven Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Sun, 02/23 20:10, Peter Lieven wrote: > Am 22.02.2014 17:45, schrieb Fam Zheng: > > On Sat, 02/22 14:00, Peter Lieven wrote: > >> this patch tries to optimize zero write requests > >> by automatically using bdrv_write_zeroes if it is > >> supported by the format. > >> > >> i know that there is a lot of potential for discussion, but i would > >> like to know what the others think. > >> > >> this should significantly speed up file system initialization and > >> should speed zero write test used to test backend storage performance. > >> > >> the difference can simply be tested by e.g. > >> > >> dd if=/dev/zero of=/dev/vdX bs=1M > >> > >> Signed-off-by: Peter Lieven > >> --- > > With this patch, is is still possible to actually do zero fill? Prefill is > > usually writing zeroes too, but according to the semantic, bdrv_write_zeroes > > may just set L2 entry flag without allocating clusters, which won't satisfy > > that. > Can you specify which operation you exactly mean? I don't think that > there is a problem, but maybe it would be better to add a check for > bs->file != NULL so the optimization takes only place for the format > not for the protocol. > Previously, users can do dd if=/dev/zero of=/dev/vdX to force backend allocation and mapping. This is meaningful for later IO performance, but how long the dd takes doesn't matter as much, since it is a one time shot. The same in your test case: yes, mkfs time may be improved, but it comes with tradeoff with later IO's slowness: when the real user data comes, the allocation still needs to be done. I would do this in qcow2: 1. In qcow2_co_writev, allocate cluster regardless of if data is zero or not. 2. If data is zero, set QCOW2_OFLAG_ZERO in L2. Fam