From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkxCL-0000mj-0r for qemu-devel@nongnu.org; Wed, 22 Apr 2015 12:08:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkxCG-0004Pa-0J for qemu-devel@nongnu.org; Wed, 22 Apr 2015 12:08:24 -0400 Received: from relay.parallels.com ([195.214.232.42]:57361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkxCF-0004PO-O4 for qemu-devel@nongnu.org; Wed, 22 Apr 2015 12:08:19 -0400 Message-ID: <5537C129.401@odin.com> Date: Wed, 22 Apr 2015 18:41:29 +0300 From: "Denis V. Lunev" 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> <5537AF4A.8050505@openvz.org> In-Reply-To: <5537AF4A.8050505@openvz.org> 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi On 22/04/15 17:25, 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=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. #define _GNU_SOURCE #include #include #include #include #include #include int main(int argc, char *argv[]) { int fd = open(argv[1], O_WRONLY | O_CREAT | O_DIRECT | O_TRUNC, 0644); void *buf; int i = 0; buf = memalign(4096, 65536); memset(buf, 0x11, 65536); for (i = 0; i < 1024 * 64; i++) { write(fd, buf, 65536); } close(fd); return 0; } # with O_TRUNC in the test hades /vol $ time for i in `seq 1 10` ; do ./a.out aa ; done real 3m4.031s user 0m0.123s sys 0m18.902s hades /vol hades /vol $ hades /vol $ # without O_TRUNC in the test (file exists) hades /vol $ time for i in `seq 1 10` ; do ./a.out aa ; done real 2m56.770s user 0m0.133s sys 0m10.756s hades /vol $ The difference for this case (ext4) is 5%. hades ~ $ uname -a Linux hades 3.16.0-34-generic #47~14.04.1-Ubuntu SMP Fri Apr 10 17:49:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux hades ~ $