On Tue, May 11, 2010 at 11:11:12PM +0100, Paul Brook wrote:
.. though it may be a kernel bug rather that a qemu bug, depending on the
exact details. Either way, I consider any mode that inhibits host filesystem
write cache but not volatile drive cache to be pretty worthless. Either we
On Fri, May 14, 2010 at 11:16:47AM +0200, Markus Armbruster wrote:
If you change -drive, please keep the coming separation in mind, and
avoid parameters that mix up guest and host.
This new option seems to be exactly that, unfortunately..
On 17.05.2010, at 14:41, Christoph Hellwig wrote:
On Fri, May 14, 2010 at 11:16:47AM +0200, Markus Armbruster wrote:
If you change -drive, please keep the coming separation in mind, and
avoid parameters that mix up guest and host.
This new option seems to be exactly that, unfortunately..
Christoph Hellwig h...@lst.de writes:
[...]
Markus was looking into separating the block device state in host/
guest portions lately, and splitting cache= would help with this.
Driver cache enabled or not (fsync means enabled, O_DSYNC disabled,
and none probably disabled given that we don't
Paul Brook wrote:
Paul Brook wrote:
cache=none:
No host caching. Reads and writes both go directly to underlying
storage.
Useful to avoid double-caching.
cache=writethrough
Reads are cached. Writes go directly to underlying storage. Useful
for
Kevin Wolf wrote:
Am 10.05.2010 23:51, schrieb Alexander Graf:
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new parameter to -drive that allows us to set the flushing
behavior
Am 12.05.2010 17:05, schrieb Alexander Graf:
Kevin Wolf wrote:
Am 10.05.2010 23:51, schrieb Alexander Graf:
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new parameter to -drive
Am 12.05.2010 um 17:36 schrieb Kevin Wolf kw...@redhat.com:
Am 12.05.2010 17:05, schrieb Alexander Graf:
Kevin Wolf wrote:
Am 10.05.2010 23:51, schrieb Alexander Graf:
Usually the guest can tell the host to flush data to disk. In
some cases we
don't want to flush though, but try to keep
Am 10.05.2010 23:51, schrieb Alexander Graf:
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new parameter to -drive that allows us to set the flushing
behavior to on or off,
On Tue, May 11, 2010 at 10:36:24AM +0200, Kevin Wolf wrote:
Am 10.05.2010 23:51, schrieb Alexander Graf:
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new parameter to -drive
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 agree.
The cache option really isn't too useful. There's a
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
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
On 05/11/2010 08:12 AM, Paul Brook wrote:
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
In a development environment the rules can be a bit different. For
example if you're testing an OS installer then you really don't want to
be passing magic mount options. If the host machine dies then you don't
care about the state of the guest because you're going to start from
scratch
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 agree.
The cache option really isn't
On 05/11/2010 08:50 AM, Paul Brook wrote:
In a development environment the rules can be a bit different. For
example if you're testing an OS installer then you really don't want to
be passing magic mount options. If the host machine dies then you don't
care about the state of the guest because
Anthony Liguori wrote:
On 05/11/2010 08:12 AM, Paul Brook wrote:
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
On 05/11/2010 10:53 AM, Paul Brook wrote:
I disagree. We should not be removing or rejecting features just because
they allow you to shoot yourself in the foot. We probably shouldn't be
enabling them by default, but that's a whole different question.
I disagree and think the mentality
On 05/11/2010 11:32 AM, Jamie Lokier wrote:
Anthony Liguori wrote:
On 05/11/2010 08:12 AM, Paul Brook wrote:
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
Anthony Liguori wrote:
qemu-img create -f raw foo.img 10G
mkfs.ext3 foo.img
mount -oloop,rw,barrier=1 -t ext3 foo.img mnt
Works perfectly fine.
Hmm, interesting. Didn't know loop propagated barriers.
So you're suggesting to use qemu with a loop device, and ext2 (bit
faster than ext3) and
Paul Brook wrote:
cache=none:
No host caching. Reads and writes both go directly to underlying storage.
Useful to avoid double-caching.
cache=writethrough
Reads are cached. Writes go directly to underlying storage. Useful for
broken guests that aren't aware of drive caches.
These
On 05/11/2010 11:36 AM, Kevin Wolf wrote:
Am 10.05.2010 23:51, schrieb Alexander Graf:
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new parameter to -drive that allows us to set
On 05/11/2010 06:40 PM, Anthony Liguori wrote:
But if the goal is to make sure that fsync's don't result in data
actually being on disk, there are many other ways to accomplish this.
First, for the vast majority of users, this is already the case
because ext3 defaults to disabling barriers.
Paul Brook wrote:
cache=none:
No host caching. Reads and writes both go directly to underlying
storage.
Useful to avoid double-caching.
cache=writethrough
Reads are cached. Writes go directly to underlying storage. Useful for
broken guests that aren't aware of drive
Paul Brook wrote:
cache=none:
No host caching. Reads and writes both go directly to underlying
storage.
Useful to avoid double-caching.
cache=writethrough
Reads are cached. Writes go directly to underlying storage. Useful
for
broken guests that
On 05/11/2010 10:53 AM, Paul Brook wrote:
I disagree. We should not be removing or rejecting features just
because they allow you to shoot yourself in the foot. We probably
shouldn't be enabling them by default, but that's a whole different
question.
I disagree and think the
27 matches
Mail list logo
