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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/15/2010 03:30 AM, Kevin Wolf wrote:
> 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).
>    

Don't you have to write both a reference count entry and update the L2 
entry?  Both calls would be bdrv_pwrite_sync, no?

Regards,

Anthony Liguori

> Kevin
>