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

[Zhi Yong Wu]

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



-- 
Regards,

Zhi Yong Wu