From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60725)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1YGMHy-0006vy-Sg
	for qemu-devel@nongnu.org; Wed, 28 Jan 2015 01:39:47 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1YGMHt-0006tB-Tf
	for qemu-devel@nongnu.org; Wed, 28 Jan 2015 01:39:46 -0500
Received: from mx2.parallels.com ([199.115.105.18]:54051)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1YGMHt-0006t7-OU
	for qemu-devel@nongnu.org; Wed, 28 Jan 2015 01:39:41 -0500
Message-ID: <54C88420.60202@openvz.org>
Date: Wed, 28 Jan 2015 09:39:28 +0300
From: "Denis V. Lunev" <den@openvz.org>
MIME-Version: 1.0
References: <1422366699-17473-1-git-send-email-den@openvz.org>
	<1422366699-17473-8-git-send-email-den@openvz.org>
	<54C7D354.2030003@redhat.com>
In-Reply-To: <54C7D354.2030003@redhat.com>
Content-Type: text/plain; charset="iso-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 7/7] block/raw-posix: set max_write_zeroes
 to INT_MAX for regular files
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: Max Reitz <mreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Peter Lieven <pl@kamp.de>, Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

On 27/01/15 21:05, Max Reitz wrote:
> On 2015-01-27 at 08:51, Denis V. Lunev wrote:
>> fallocate() works fine and could handle properly with arbitrary size
>> requests.
>
> Maybe "could properly handle arbitrary size requests" (or 
> "...arbitrarily sized requests")?
>
>> There is no sense to reduce the amount of space to fallocate.
>> The bigger is the size, the better is the performance as the amount of
>> journal updates is reduced.
>
> True for fallocate(). But is it true for xfs_write_zeroes(), too? I 
> guess so, but I don't know.
>
> If it does, the patch looks good to me.
>
> Max
>

checked.

xfs_ioc_space (ioctl handler) calls exactly the same xfs_zero_file_space as
performed by xfs_file_fallocate on fallocate path.

I will reflect this in the description

Regards,
     Den