From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52247)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VTRJE-0007cu-2Q
	for qemu-devel@nongnu.org; Tue, 08 Oct 2013 03:02:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VTRJ7-0007H3-Kq
	for qemu-devel@nongnu.org; Tue, 08 Oct 2013 03:02:19 -0400
Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b]:47629)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VTRJ7-0007Gr-DK
	for qemu-devel@nongnu.org; Tue, 08 Oct 2013 03:02:13 -0400
Received: by mail-lb0-f171.google.com with SMTP id u14so6404066lbd.2
	for <qemu-devel@nongnu.org>; Tue, 08 Oct 2013 00:02:12 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <525281F6.5070709@redhat.com>
References: <1380029714-5239-1-git-send-email-pl@kamp.de>
	<20131007084259.GF6254@stefanha-thinkpad.redhat.com>
	<525281F6.5070709@redhat.com>
Date: Tue, 8 Oct 2013 09:02:12 +0200
Message-ID: <CAJSP0QVg1kS5UpHQu7EsNJtpYs_Y3Z_sY=7FXyNMdm0xarRHmg@mail.gmail.com>
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Qemu-devel] [PATCHv3 00/20] block: logical block provisioning
	enhancements
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>, Peter Lieven <pl@kamp.de>, qemu-devel <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@redhat.com>, ronnie sahlberg <ronniesahlberg@gmail.com>

On Mon, Oct 7, 2013 at 11:42 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 07/10/2013 10:42, Stefan Hajnoczi ha scritto:
>> 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 ;)
>
> The flag is needed to implement the right semantics for the SCSI WRITE
> SAME command, which are:
>
> - if the UNMAP bit is off, always write the sectors (that's
> bdrv_aio_write_zeroes without BDRV_REQ_MAY_UNMAP if the payload is zero,
> otherwise it's emulated with bdrv_aio_writev)
>
> - if the target can "discard and write the specified payload", you can
> discard, else you must write the sectors with the correct payload
> (that's bdrv_aio_write_zeroes with BDRV_REQ_MAY_UNMAP).
>
> Contrast this with the UNMAP command, which does not make any guarantee
> on the content of the sectors after the command is completed (a few
> months ago we agreed that, even if you have discard_zeroes=true in the
> target, it is fine for UNMAP to do nothing).

Okay, then let's keep the patches to expose the flag.

Stefan