From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:39749)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RuQwL-0007jn-De
	for qemu-devel@nongnu.org; Mon, 06 Feb 2012 10:57:18 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RuQwC-0005Cv-1E
	for qemu-devel@nongnu.org; Mon, 06 Feb 2012 10:57:13 -0500
Received: from mx1.redhat.com ([209.132.183.28]:37931)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RuQwB-0005Cn-Qu
	for qemu-devel@nongnu.org; Mon, 06 Feb 2012 10:57:03 -0500
Message-ID: <4F2FF91B.5050203@redhat.com>
Date: Mon, 06 Feb 2012 17:00:27 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1326898793-20331-1-git-send-email-stefanha@linux.vnet.ibm.com>
	<1326898793-20331-3-git-send-email-stefanha@linux.vnet.ibm.com>
	<4F1ECB37.10701@redhat.com>
	<CAJSP0QXSbtjoCk3JPp7SiY+vU577zAXwUuntmhQXB5mZmR6bxQ@mail.gmail.com>
In-Reply-To: <CAJSP0QXSbtjoCk3JPp7SiY+vU577zAXwUuntmhQXB5mZmR6bxQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v4 2/6] block: add .bdrv_co_write_zeroes()
 interface
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: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel@nongnu.org

Am 06.02.2012 16:50, schrieb Stefan Hajnoczi:
> On Tue, Jan 24, 2012 at 3:16 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>>> +/*
>>> + * Efficiently zero a region of the disk image.  Note that this is a regular
>>> + * I/O request like read or write and should have a reasonable size.  This
>>> + * function is not suitable for zeroing the entire image in a single request.
>>> + */
>>
>> The reason for this is that in the fallback case you allocate memory for
>> the whole request, right? So what about just limiting the allocation in
>> bdrv_co_do_write_zeroes() to a reasonable size and putting a loop there
>> for large requests?
> 
> I'd rather not do that yet.  We don't have a reasonable way to cancel
> such a request yet.  In the future, if we decide we'd like to do huge
> bdrv_co_write_zeroes(), we could look at the details of making this
> work.

Do we even need a way to cancel such requests?

But anyway, include the reason in the comment, then we can leave it as
it is.

Kevin