qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixi


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
Date: Thu, 31 May 2012 10:26:40 +0100

On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu <address@hidden> wrote:
> On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf <address@hidden> wrote:
>> A prerequisite for a "QED mode" in qcow2, which doesn't update the refcount
> Recently some new concepts such as "QED mode" in qcow2 are seen
> frequencely, can anyone explain what it means? thanks.

qcow2 has more metadata than qed.  More metadata means more write
operations when allocating new clusters.

In order to overcome this performance issue qcow2 has a metadata
cache.  But when QEMU is launched with -drive ...,cache=writethrough
(the default) the metadata cache *must* be in writethrough mode
instead of writeback mode.  In other words, every metadata update
needs to be written to the image file before we complete the guest's
write request.  This means the metadata cache only hides the metadata
performance issue when -drive ...,cache=direct|writeback are used
because there we can keep metadata changes buffered in memory until
the guest flushes the emulated disk write cache.

"QED mode" is a solution for -drive ...,cache=writethrough|directsync.
 It simply doesn't update refcount metadata in the qcow2 image file
immediately in exchange for a refcount fixup step that is introduced
when opening the image file.  It's like doing an fsck operation on a
file system when mounting it.

Stefan



reply via email to

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