[Qemu-devel] Re: Caching modes

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/20/2010 02:34 PM, Christoph Hellwig wrote:
> On Mon, Sep 20, 2010 at 11:53:02AM -0500, Anthony Liguori wrote:
>    
>> cache=none
>>
>> All read and write requests SHOULD avoid any type of caching in the
>> host.  Any write request MUST complete after the next level of storage
>> reports that the write request has completed.  A flush from the guest
>> MUST complete after all pending I/O requests for the guest have been
>> completed.
>>
>> As an implementation detail, with the raw format, these guarantees are
>> only in place for preallocated images.  Sparse images do not provide as
>> strong of a guarantee.
>>      
> That's not how cache=none ever worked nor works currently.
>    

How does it work today compared to what I wrote above?

> But discussion the current cache modes is rather mood as they try to
> map multi-dimension behaviour difference into a single options.  I have
> some patches that I need to finish up a bit more that will give you
> your no caching enabled mode, but I don't think mapping cache=none to it
> will do anyone a favour.
>
> With the split between the guest visible write-cache-enable (WCE) flag, and
> the host-specific "use O_DIRECT" and "ignore cache flushes" flags we'll
> get the following modes:
>
>
>                        | WC enable | WC disable
> -----------------------------------------------
> direct                |           |
> buffer                |           |
> buffer + ignore flush |           |
>
> currently we only have:
>
>   cache=none		direct + WC enable
>   cache=writeback	buffer + WC enable
>   cache=writethrough	buffer + WC disable
>   cache=unsafe		buffer + ignore flush + WC enable
>    

Where does O_DSYNC fit into this chart?

Do all modern filesystems implement O_DSYNC without generating 
additional barriers per request?

Having a barrier per-write request is ultimately not the right semantic 
for any of the modes.  However, without the use of O_DSYNC (or 
sync_file_range(), which I know you dislike), I don't see how we can 
have reasonable semantics without always implementing write back caching 
in the host.

> splitting these up is important because we want to migrate between
> hosts that can support direct I/O or not without requiring guest visible
> state changes, and also because we want to use direct I/O with guest
> that were installed using cache=unsafe without stopping the guest.
>
> It also allows the guest to change the WC enable/disable flag, which
> they can do for real IDE/SCSI hardware.  And it allows Anthony's belowed
> no caching at all mode, which actually is useful for guest that can not
> deal with volatile write caches.
>    

I'm certainly happy to break up the caching option.  However, I still 
don't know how we get a reasonable equivalent to cache=writethrough 
without assuming that ext4 is mounted without barriers enabled.

Regards,

Anthony Liguori