Am 14.09.2010 17:11, schrieb Anthony Liguori: > On 09/14/2010 09:47 AM, Chris Wright wrote: >> 0.13 >> - if all goes well...tomorrow >> > > To tag, it may be thursday for announcement. I need to run a regression > run tonight. > >> qed/qcow2 >> - increase concurrency, performance >> > > To achieve performance, a block driver must: 1) support concurrent > request handling 2) not hold the qemu_mutex for prolonged periods of time. > > QED never does (2) and supports (1) in all circumstances except cluster > allocation today. > > qcow2 can do (1) for the data read/write portions of an I/O request. > All metadata read/write is serialized. It also does (2) for all > metadata operations and for CoW operations. > > These are implementation details though. The real claim of QED is that > by having fewer IO ops required to satisfy a request, it achieves better > performance especially since it achieves zero syncs in the cluster > allocation path. qcow2 has two syncs in the cluster allocation path > today. One sync is due to the refcount table. Another sync is due to > the fact that it doesn't require fsck support.
The refcount table sync is the sync that allows not doing an fsck. For a simple cluster allocation (no L2 allocation, no COW), we only have one sync (which is still one sync too much in this path, so we must move it). Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
