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

[Stefan Hajnoczi]

On Wed, Jun 6, 2012 at 3:53 PM, Zhi Yong Wu <address@hidden> wrote:
> On Wed, Jun 6, 2012 at 6:32 PM, Stefan Hajnoczi <address@hidden> wrote:
>> 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).
> Ah, i see now, cache=writethrough mean that host page cache is applied
> to read request, not write. thanks.

Writes are placed in the host page cache so future reads can be served
from the cache.  But O_SYNC also forces the kernel to immediately sync
the data in the host page cache to disk.

Stefan