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.

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

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.


Reply via email to