[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qcow2: Metadata preallocation

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: 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]