All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel <qemu-devel@nongnu.org>, Kevin Wolf <kwolf@redhat.com>,
	Christoph Hellwig <hch@lst.de>
Subject: [Qemu-devel] Caching modes
Date: Mon, 20 Sep 2010 11:53:02 -0500	[thread overview]
Message-ID: <4C97916E.2080801@codemonkey.ws> (raw)

Moving to a separate thread since this has come up a few times and I 
think we need to discuss the assumptions a bit more.

This is how I understand the caching modes should behave and what 
guarantees a guest gets.

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.

cache=writethrough

All read and write requests MAY be cached by the host.  Read requests 
MAY be satisfied by cached data 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 also 
apply for sparse images.  In the future, we could relax this such that 
sparse images did not provide as strong of a guarantee.

cache=writeback

All read and writes requests MAY be cached by the host.  Read and write 
requests may be completed entirely within the cache.  A write request 
MAY complete before 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 and acknowledged 
by the next level of the storage hierarchy.

Guest disk cache.

For all devices that support it, the exposed cache attribute should be 
independent of the host caching mode.  Here are correct usages of disk 
caching mode:

Writethrough disk cache; cache=none|writethrough if the disk cache is 
set to writethrough or the disk is considered "enterprise class" and has 
a battery backup.  cache=writeback IFF the host is backed by an UPS.

Writeback disk cache; cache=none|writethrough if the disk cache is set 
to writeback and the disk is not enterprise class.  cache=writeback if 
the host is not backed by an UPS.

Regards,

Anthony Liguori

             reply	other threads:[~2010-09-20 16:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-20 16:53 Anthony Liguori [this message]
2010-09-20 18:37 ` [Qemu-devel] Caching modes Blue Swirl
2010-09-20 18:51   ` Anthony Liguori
2010-09-20 19:34 ` [Qemu-devel] " Christoph Hellwig
2010-09-20 20:11   ` Anthony Liguori
2010-09-20 23:17     ` Christoph Hellwig
2010-09-21  0:18       ` Anthony Liguori
2010-09-21  8:15         ` Kevin Wolf
2010-09-21 14:26         ` Christoph Hellwig
2010-09-21 15:13           ` Anthony Liguori
2010-09-21 20:57             ` Christoph Hellwig
2010-09-21 21:27               ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C97916E.2080801@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.