qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: KVM call minutes for Sept 14
Date: Wed, 15 Sep 2010 10:30:16 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]