[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive
Date: Tue, 11 May 2010 07:43:12 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 05/11/2010 07:15 AM, Paul Brook wrote:
What about another cache=... value instead of adding more options? I'm
quite sure you'll only ever need this with writeback caching. So we
could have cache=none|writethrough|writeback|wb-noflush or something
like that.
I think this table is misleading, and from a user perspective there are only 4
interesting combinations:

I agree that splitting cache would be unfortunate for users.

   No host caching. Reads and writes both go directly to underlying storage.
Useful to avoid double-caching.

   Reads are cached. Writes go directly to underlying storage.  Useful for
broken guests that aren't aware of drive caches.

   Reads and writes are cached. Guest flushes are honoured. Note that this may
include a guest visible knob that allows the write cache to be disabled. If
the guest requests the cache be disabled then this should act the same as
cache=writethrough. Closest to how real hardware works.

cache=always (or a more scary name like cache=lie to defend against idiots)
   Reads and writes are cached. Guest flushes are ignored.  Useful for dumb
guests in non-critical environments.

I really don't believe that we should support a cache=lie. There are many other obtain the same results. For instance, mount your guest filesystem with barrier=0.

Introducing a mode where data integrity isn't preserved means that it's possible for someone to accidentally use it or use it when they really shouldn't. People already struggle with what caching mode they should use and this would just make the problem worse.


Anthony Liguori

IMO the other boxes in your table (disable cache but require guest flushes)
don't make any sense.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]