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

[Avi Kivity <avi@redhat.com>]

  On 09/20/2010 05:51 PM, Anthony Liguori wrote:
> 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.
>
> Would it be a mortal sin to open the file twice and have a cache=none 
> version for data and cache=writeback for metadata?
>
> The two definitely aren't consistent with each other but I think the 
> whole point here is that we don't care.
>
> It opens up some other possibilities too like cache=none for data and 
> cache=writethrough for metadata which may be a useful combination.

I've thought of this (and I think perhaps suggested it on this list).  
The question is whether the kernel doesn't slow direct io when page 
cache is present for the file (but in unconflicting ranges).

I think it's considered a valid use case (backing up a database file 
while the database is O_DIRECTing into it) but I don't know if the code 
was actually updated to support this.

-- 
error compiling committee.c: too many arguments to function