From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT6PH-0000CZ-8P for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:43:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VT6P8-0002Jg-J8 for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:43:11 -0400 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:34492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT6P8-0002Ja-C8 for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:43:02 -0400 Received: by mail-we0-f170.google.com with SMTP id u57so5770767wes.1 for ; Mon, 07 Oct 2013 01:43:01 -0700 (PDT) Date: Mon, 7 Oct 2013 10:42:59 +0200 From: Stefan Hajnoczi Message-ID: <20131007084259.GF6254@stefanha-thinkpad.redhat.com> References: <1380029714-5239-1-git-send-email-pl@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1380029714-5239-1-git-send-email-pl@kamp.de> 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: Peter Lieven Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, pbonzini@redhat.com, ronniesahlberg@gmail.com 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 = 1. > > 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. 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... 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. Or maybe I just missed something ;) Stefan