From: Kevin Wolf <kwolf@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] KVM call agenda for October 25
Date: Tue, 25 Oct 2011 17:32:06 +0200 [thread overview]
Message-ID: <4EA6D676.2060907@redhat.com> (raw)
In-Reply-To: <4EA6C25C.8000502@codemonkey.ws>
Am 25.10.2011 16:06, schrieb Anthony Liguori:
> On 10/25/2011 08:56 AM, Kevin Wolf wrote:
>> Am 25.10.2011 15:05, schrieb Anthony Liguori:
>>> On 10/25/2011 07:35 AM, Kevin Wolf wrote:
>>>> Am 24.10.2011 13:35, schrieb Paolo Bonzini:
>>>>> On 10/24/2011 01:04 PM, Juan Quintela wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Please send in any agenda items you are interested in covering.
>>>>>
>>>>> - What's left to merge for 1.0.
>>>>
>>>> I would still like to cache the default cache mode (probably to
>>>> cache=writeback). We don't allow guests to toggle WCE yet which Anthony
>>>> would have liked to see before doing the change. Is it a strict requirement?
>>>
>>> I don't see a way around it. If the default mode is cache=writeback, then we're
>>> open to data corruption in any guest where barrier=0. With guest togglable WCE,
>>> it ends up being a guest configuration issue so we can more or less defer
>>> responsibility.
>>
>> So do you think that offering a WCE inside the guest would be a real
>> solution or just a way to have an excuse?
>
> No, it offers a mechanism to "fix mistakes" at run-time verses at start up time.
This is true (in both directions). But I think it's independent from the
right default.
> It also means that you can make template images that understand that they
> don't support barriers and change the WCE setting appropriately.
Isn't that really a job for management tools?
>> Christoph said that OSes don't usually change this by themselves, it
>> would need an administrator manually changing the setting. But if we
>> require that, we can just as well require that the administrator set
>> cache=writethrough on the qemu command line.
>
> The administrator of the guest != the administrator of the host.
But the administrator of the guest == the owner of the qemu instance,
no? He should be the one to use the management tools and configure his VMs.
>>> Do you think it's a good idea to change the default mode w/o guest WCE toggle
>>> support? What's your view about older guests if we change the default mode?
>>> What's your main motivation for wanting to change the default mode?
>>
>> Because people are constantly complaining about the awful
>> (cache=writethrough) performance they get before they are told they
>> should use a different cache option. And they are right. The
>> out-of-the-box experience with qemu's block performance really sucks.
>
> With qcow2 you mean, right?
No, with any format, including raw. Which isn't surprising at all,
O_SYNC makes writes very expensive.
>>> I'd be much more open to changing the default mode to cache=none FWIW since the
>>> risk of data loss there is much, much lower.
>>
>> I think people said that they'd rather not have cache=none as default
>> because O_DIRECT doesn't work everywhere.
>
> Where doesn't it work these days? I know it doesn't work on tmpfs. I know it
> works on ext[234], btrfs, nfs.
I think tmpfs was named (and failing to start with default settings on
tmpfs would be nasty enough), but iirc Alex had another one.
Kevin
next prev parent reply other threads:[~2011-10-25 15:29 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-24 11:04 KVM call agenda for October 25 Juan Quintela
2011-10-24 11:04 ` [Qemu-devel] " Juan Quintela
2011-10-24 11:35 ` Paolo Bonzini
2011-10-24 11:35 ` [Qemu-devel] " Paolo Bonzini
2011-10-24 12:02 ` Peter Maydell
2011-10-24 13:06 ` Andreas Färber
2011-10-24 13:06 ` [Qemu-devel] " Andreas Färber
2011-10-24 15:34 ` Luiz Capitulino
2011-10-25 12:35 ` Kevin Wolf
2011-10-25 12:35 ` [Qemu-devel] " Kevin Wolf
2011-10-25 13:05 ` Anthony Liguori
2011-10-25 13:18 ` Dor Laor
2011-10-25 13:28 ` Anthony Liguori
2011-10-25 13:40 ` Andreas Färber
2011-10-25 13:40 ` Andreas Färber
2011-10-25 13:56 ` Kevin Wolf
2011-10-25 14:06 ` Anthony Liguori
2011-10-25 15:32 ` Kevin Wolf [this message]
2011-10-25 22:19 ` Alexander Graf
2011-10-25 22:19 ` [Qemu-devel] " Alexander Graf
2011-10-26 20:41 ` Anthony Liguori
2011-10-26 8:15 ` Kevin Wolf
2011-10-26 8:15 ` [Qemu-devel] " Kevin Wolf
2011-10-26 8:48 ` Markus Armbruster
2011-10-26 8:48 ` Markus Armbruster
2011-10-26 9:41 ` Paolo Bonzini
2011-10-26 9:41 ` Paolo Bonzini
2011-10-26 11:12 ` Markus Armbruster
2011-10-26 9:57 ` Daniel P. Berrange
2011-10-26 11:23 ` Kevin Wolf
2011-10-26 11:23 ` Kevin Wolf
2011-10-26 11:39 ` Daniel P. Berrange
2011-10-26 11:39 ` Daniel P. Berrange
2011-10-26 12:18 ` Kevin Wolf
2011-10-26 12:18 ` Kevin Wolf
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=4EA6D676.2060907@redhat.com \
--to=kwolf@redhat.com \
--cc=agraf@suse.de \
--cc=anthony@codemonkey.ws \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@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.