|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH] qcow2: Metadata preallocation |
Date: | Mon, 17 Aug 2009 10:45:33 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 |
On 08/17/2009 10:11 AM, Kevin Wolf wrote:
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.
What I meant was that I prefer changes that improve performance throughout the lifetime of the image rather than the initial writes, especially as there's a space tradeoff. It is not a strong objection, just a mild preference.
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.
Ah, I looked at the open code and missed it. -- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |