From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55839)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1Ykvaq-00021h-IX
	for qemu-devel@nongnu.org; Wed, 22 Apr 2015 10:25:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1Ykvah-0002jj-LR
	for qemu-devel@nongnu.org; Wed, 22 Apr 2015 10:25:36 -0400
Received: from relay.parallels.com ([195.214.232.42]:39283)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1Ykvah-0002jP-Dg
	for qemu-devel@nongnu.org; Wed, 22 Apr 2015 10:25:27 -0400
Message-ID: <5537AF4A.8050505@openvz.org>
Date: Wed, 22 Apr 2015 17:25:14 +0300
From: "Denis V. Lunev" <den@openvz.org>
MIME-Version: 1.0
References: <1426069701-1405-1-git-send-email-den@openvz.org>
	<1426069701-1405-27-git-send-email-den@openvz.org>
	<20150422141848.GA27617@stefanha-thinkpad.redhat.com>
In-Reply-To: <20150422141848.GA27617@stefanha-thinkpad.redhat.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 26/27] block/parallels: optimize linear
 image expansion
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: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

On 22/04/15 17:18, Stefan Hajnoczi wrote:
> On Wed, Mar 11, 2015 at 01:28:20PM +0300, Denis V. Lunev wrote:
>> Plain image expansion spends a lot of time to update image file size.
>> This seriously affects the performance. The following simple test
>>    qemu_img create -f parallels -o cluster_size=64k ./1.hds 64G
>>    qemu_io -n -c "write -P 0x11 0 1024M" ./1.hds
>> could be improved if the format driver will pre-allocate some space
>> in the image file with a reasonable chunk.
>>
>> This patch preallocates 128 Mb using bdrv_write_zeroes, which should
>> normally use fallocate() call inside. Fallback to older truncate()
>> could be used as a fallback using image open options thanks to the
>> previous patch.
>>
>> The benefit is around 15%.
> qcow2 doesn't use bdrv_truncate() at all.  It simply writes past the end
> of bs->file to grow the file.  Can you use this approach instead?
this is worse from performance point of view.

OK, there is no difference if big write will come from guest. In
this case single write will do the job just fine. Though if the
file will be extended by several different write the situation
will be different. Each write will update inode metadata.
Welcome journal write. This metadata update will cost us
even more in the case of network filesystem and much more
in the case of distributed filesystem (additional MDS write
transaction at least).

This is the main reason to follow this approach here.