Re: [Qemu-devel] [RFC] block-queue: Delay and batch metadata writes

[Kevin Wolf <kwolf@redhat.com>]

Am 20.09.2010 17:40, schrieb Anthony Liguori:
> On 09/20/2010 10:08 AM, Kevin Wolf wrote:
>>> If you're comfortable with a writeback cache for metadata, then you
>>> should also be comfortable with a writeback cache for data in which
>>> case, cache=writeback is the answer.
>>>      
>> Well, there is a difference: We don't pollute the host page cache with
>> guest data and we don't get a virtual "disk cache" as big as the host
>> RAM, but only a very limited queue of metadata.
>>
>> Basically, in qemu we have three different types of caching:
>>
>> 1. O_DSYNC, everything is always synced without any explicit request.
>>     This is cache=writethrough.
>>    
> 
> I actually think O_DSYNC is the wrong implementation of 
> cache=writethrough.  cache=writethrough should behave just like 
> cache=none except that data goes through the page cache.

Then you have cache=writeback, basically.

>> 2. Nothing is ever synced. This is cache=unsafe.
>>
>> 3. We present a writeback disk cache to the guest and the guest needs
>>     to explicitly flush to gets its data safe on disk. This is
>>     cache=writeback and cache=none.
>>    
> 
> We shouldn't tie the virtual disk cache to which cache= option is used 
> in the host.  cache=none means that all requests go directly to the 
> disk.  cache=writeback means the host acts as a writeback cache.

No, that's not the meaning of cache=none if you take the disk cache into
consideration. It might be what you think should be the meaning of
cache=none, but it's not what it means in any qemu release.

> If your disk is in writethrough mode, exposing cache=none as a writeback 
> disk cache is not correct.

The host's disk is writethrough? In this case it's being more
conservative than needed, yes.

>> We're still lacking modes for O_DSYNC | O_DIRECT and unsafe | O_DIRECT,
>> but they are entirely possible, because it's two different dimensions.
>> (And I think Christoph was planning to actually make it two independent
>> options)
> 
> I don't really think O_DSYNC | O_DIRECT makes much sense.

Maybe, maybe not. It's just a missing entry in the matrix.

Kevin