On Sun, Mar 07, 2010 at 04:42:18PM +0200, Avi Kivity wrote:
This means that if I start a guest with cache=writethrough and then
restart (or live migrate) it with cache=none, then the guest will see a
change, even though the user only changed the drive's backing, not
something guest visible.
On 03/08/2010 11:39 AM, Christoph Hellwig wrote:
On Sun, Mar 07, 2010 at 04:42:18PM +0200, Avi Kivity wrote:
This means that if I start a guest with cache=writethrough and then
restart (or live migrate) it with cache=none, then the guest will see a
change, even though the user only changed
Christoph Hellwig wrote:
On Sun, Mar 07, 2010 at 04:42:18PM +0200, Avi Kivity wrote:
This means that if I start a guest with cache=writethrough and then
restart (or live migrate) it with cache=none, then the guest will see a
change, even though the user only changed the drive's backing,
On Mon, Mar 08, 2010 at 09:47:32AM +, Jamie Lokier wrote:
Assuming the outcome is that it becomes a qdev property, and stays
preserved across migrations, even if the backing device access
changes, then I think the right thing is to dynamically decide to set
O_DSYNC and/or call fdatasync
block.c says:
/*
* Yes, BDRV_O_NOCACHE aka O_DIRECT means we have to present a
* write cache to the guest. We do need the fdatasync to flush
* out transactions for block allocations, and we maybe have a
* volatile write cache in our backing device to deal with.
*/
