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