From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1McwOi-0003tf-7P for qemu-devel@nongnu.org; Mon, 17 Aug 2009 03:12:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1McwOd-0003oa-Gg for qemu-devel@nongnu.org; Mon, 17 Aug 2009 03:12:51 -0400 Received: from [199.232.76.173] (port=60941 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McwOd-0003oK-Dc for qemu-devel@nongnu.org; Mon, 17 Aug 2009 03:12:47 -0400 Received: from mx20.gnu.org ([199.232.41.8]:40659) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1McwOc-0004KX-SY for qemu-devel@nongnu.org; Mon, 17 Aug 2009 03:12:47 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1McwOb-0000gn-OD for qemu-devel@nongnu.org; Mon, 17 Aug 2009 03:12:46 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7H7CiGT018045 for ; Mon, 17 Aug 2009 03:12:44 -0400 Message-ID: <4A8902AA.2050200@redhat.com> Date: Mon, 17 Aug 2009 09:11:38 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow2: Metadata preallocation References: <1250262015-996-1-git-send-email-kwolf@redhat.com> <4A87F44B.5080308@redhat.com> In-Reply-To: <4A87F44B.5080308@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org Avi Kivity schrieb: > On 08/14/2009 06:00 PM, Kevin Wolf wrote: >> This introduces a qemu-img create option for qcow2 which allows the metadata to >> be preallocated, i.e. clusters are reserved in the refcount table and L1/L2 >> tables, but no data is written to them. Metadata is quite small, so this >> happens in almost no time. >> >> Especially with qcow2 on virtio this helps to gain a bit of performance during >> the initial writes. However, as soon as create a snapshot, we're back to the >> normal slow speed, obviously. So this isn't the real fix, but kind of a cheat >> while we're still having trouble with qcow2 on virtio. >> >> Note that the option is disabled by default and needs to be specified >> explicitly using qemu-img create -f qcow2 -o preallocation=metadata. >> >> > > Can't say I'm thrilled with this. I'd prefer coalescing metadata > updates on parallel writes. I don't object to this though. Even with improved concurrent cluster allocation, you might profit from metadata preallocation by having less fragmented qcow2 images which avoids splitting up requests. Not sure if this is relevant in practice though. >> + /* >> + * It is expected that the image file is large enough to actually contain >> + * all of the allocated clusters (otherwise we get failing reads after >> + * EOF). So just write some zeros to the last sector. >> + */ >> + if (cluster_offset != 0) { >> + uint8_t buf[512]; >> + memset(buf, 0, 512); >> + bdrv_write(s->hd, (cluster_offset>> 9) + num - 1, buf, 1); >> + } >> + >> > > Older versions of Windows don't support sparse files, and newer ones > need a flag. It's a good idea to set this flag when opening on Windows. I'm certainly hoping that raw-win32 is doing whatever needs to be done? The mentioned FSCTL_SET_SPARSE seems to be there at least. Kevin