From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlDOl-0004zn-6l for qemu-devel@nongnu.org; Thu, 23 Apr 2015 05:26:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlDOi-0006Gc-0O for qemu-devel@nongnu.org; Thu, 23 Apr 2015 05:26:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlDOh-0006GN-PV for qemu-devel@nongnu.org; Thu, 23 Apr 2015 05:26:15 -0400 Date: Thu, 23 Apr 2015 10:26:11 +0100 From: Stefan Hajnoczi Message-ID: <20150423092611.GD8811@stefanha-thinkpad.redhat.com> 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> <5537AF4A.8050505@openvz.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ycz6tD7Th1CMF4v7" Content-Disposition: inline In-Reply-To: <5537AF4A.8050505@openvz.org> Subject: Re: [Qemu-devel] [PATCH 26/27] block/parallels: optimize linear image expansion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org --Ycz6tD7Th1CMF4v7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 22, 2015 at 05:25:14PM +0300, Denis V. Lunev wrote: > 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=3D64k ./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. >=20 > 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). >=20 > This is the main reason to follow this approach here. You are right, this seems like a good approach. --Ycz6tD7Th1CMF4v7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVOLqzAAoJEJykq7OBq3PIRMoIAJyguxpU2WQYdDIGhRu4sjTb QGQD3XGBUAKh1m1d0he4/a0xy1/Qj1d7Wo6yfsSh7Q9k3/WLTY88vdV6xXpvcArR L+3r0SW2GjbhORsw4VzylX5l568393QL3ahVJAReqGrcBnybRP315W4N3bDS2Fc2 AEzAZtqgx5VHXb57YsdFrjbV64YTFByAnG/8esP9Brm0Yozgv7GDqZHm2qj/7vWw NDcRmLeZV9MlzMYoDTruZua8+9nJKsI8NOtNmiwhz2Axe8haR2SJcIrWcxVdox+5 SEz5dQRZ//m6rThfNo3q5vFbfVqTbj7NZTqlmSkrAZqUistKyoRx+scunrCjxgA= =gWlb -----END PGP SIGNATURE----- --Ycz6tD7Th1CMF4v7--