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.