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

[Stefan Hajnoczi]

On Fri, Jun 1, 2012 at 9:26 AM, Zhi Yong Wu <address@hidden> wrote:
> On Fri, Jun 1, 2012 at 4:06 PM, Stefan Hajnoczi <address@hidden> wrote:
>> On Fri, Jun 1, 2012 at 6:22 AM, Zhi Yong Wu <address@hidden> wrote:
>>> On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi <address@hidden> wrote:
>>>> 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
>>> Why must i be? If the option with -drive ..,cache=writethrough is
>>> specified. it means that host page cache is on while guest disk cache
>>> is off. Since the metadata cache exists in host page cache, not guest,
>>> i think that it is in writeback mode.
>>
>> Since the emulated disk write cache is off, we must ensure that guest
>> writes are on disk before completing them.  Therefore we cannot cache
>> metadata updates in host RAM - it would be lost on power failure but
> But host page cache is *on* in this mode, which means that metadata
> should be cached in host RAM. how do you explain this?

cache=writethrough means that the file is opened with O_SYNC.  Every
single write reaches the physical disk - that's why it's called a
"writethrough" cache.  Read requests, however, can be satisfied from
the host page cache.

In other words, cache=writethrough ensures that all data reaches the
disk but may give performance benefits to read-heavy workloads
(especially when guest RAM is much smaller than host RAM, so the host
page cache would have a high hit rate).

>> we promised the guest its writes reached the disk!
>>
>>>> instead of writeback mode.  In other words, every metadata update
>>>> needs to be written to the image file before we complete the guest's
>>> What will mean one guest's wirte request is completed?
>>
>> For example, virtio-blk fills in the success status code and raises an
>> interrupt.  This notifies the guest that the write is done.
> Great, thanks.
>>
>>>> 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
> l1/l2 info need to be updated to qcow2 image file?

Yes, this is necessary to ensure written data is accessible in the
future.  Without the L1/L2 tables we cannot find the data we wrote.

Stefan