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 14:38:00 +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 15.09.2010 14:26, schrieb Anthony Liguori:
> 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?

No, we don't really care if the L2 entry is on disk. If the guest want
to have its data safe it needs to issue an explicit flush anyway. The
only thing we want to achieve with bdrv_write_sync is to maintain the
right order between metadata updates to survive a crash without corruption.

Kevin



reply via email to

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