From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT6Tg-0001a6-GQ for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:47:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VT6TY-0003h9-2W for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:47:44 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:43704 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT6TX-0003gw-M1 for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:47:35 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Lieven In-Reply-To: <20131007084259.GF6254@stefanha-thinkpad.redhat.com> Date: Mon, 7 Oct 2013 10:47:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1380029714-5239-1-git-send-email-pl@kamp.de> <20131007084259.GF6254@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCHv3 00/20] block: logical block provisioning enhancements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, pbonzini@redhat.com, ronniesahlberg@gmail.com Am 07.10.2013 um 10:42 schrieb Stefan Hajnoczi : > On Tue, Sep 24, 2013 at 03:34:54PM +0200, Peter Lieven wrote: >> this patch adds the ability for targets to stay sparse during >> block migration (if the zero_blocks capability is set) and qemu-img = convert >> even if the target does not have has_zero_init =3D 1. >>=20 >> the series was especially developed for iSCSI, but it should also = work >> with other drivers with little or no adjustments. these adjustments >> should be limited to providing block provisioning information through >> get_block_info and/or honouring BDRV_REQ_MAY_UNMAP on writing zeroes. >=20 > Could you make bdrv_co_write_zeroes() always use UNMAP, if possible, = and > avoid adding the new BDRV_REQ_MAY_UNMAP flag? While reading the first > few patches in this series I wondered why there is a need to expose > flags at all... >=20 > Sometimes it is useful to distinguish between zeroing at the image > format level from discarding at the device level, but I don't think we > make use of that yet. I'd prefer to keep the interface simple for now > and add flags later, if necessary. >=20 > Or maybe I just missed something ;) >=20 There was a big discussing going on on this flags some time ago with = Paolo and Kevin and they wanted to have it. (thread was "qemu-img: conditionally discard target on convert"). For my = use case I don't need the flag. Peter=