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