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, unfortunate
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 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
>
Christoph Hellwig 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 care), wh
Am 12.05.2010 um 17:36 schrieb Kevin Wolf :
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 cac
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 para
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
>>
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
> 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 disagre
> > 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
> > > f
> 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 ar
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.
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 th
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.
T
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)
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 non-crit
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
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 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 severely hurts usability. QEMU's
>
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 yo
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
> > 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
> >
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 cac
> > 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 othe
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 misle
> > 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
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 -d
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", d
28 matches
Mail list logo
