Re: [Qemu-devel] Re: KVM call minutes for Sept 14

[Kevin Wolf <kwolf@redhat.com>]

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