[Qemu-devel] Re: Caching modes

[Anthony Liguori]

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