On Wed, Jun 6, 2012 at 6:32 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Fri, Jun 1, 2012 at 9:26 AM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote: >> On Fri, Jun 1, 2012 at 4:06 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >>> On Fri, Jun 1, 2012 at 6:22 AM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote: >>>> On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi <stefa...@gmail.com> >>>> wrote: >>>>> On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote: >>>>>> On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf <kw...@redhat.com> 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
