From: Christoph Hellwig <hch@lst.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
Christoph Hellwig <hch@lst.de>
Subject: [Qemu-devel] Re: Caching modes
Date: Mon, 20 Sep 2010 21:34:51 +0200 [thread overview]
Message-ID: <20100920193451.GA11516@lst.de> (raw)
In-Reply-To: <4C97916E.2080801@codemonkey.ws>
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.
next prev parent reply other threads:[~2010-09-20 19:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 16:53 [Qemu-devel] Caching modes Anthony Liguori
2010-09-20 18:37 ` Blue Swirl
2010-09-20 18:51 ` Anthony Liguori
2010-09-20 19:34 ` Christoph Hellwig [this message]
2010-09-20 20:11 ` [Qemu-devel] " 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=20100920193451.GA11516@lst.de \
--to=hch@lst.de \
--cc=anthony@codemonkey.ws \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).