Re: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"

[Kevin Wolf <kwolf@redhat.com>]

Am 24.08.2010 14:39, schrieb Avi Kivity:
>   On 08/24/2010 03:35 PM, Kevin Wolf wrote:
>>
>>> I don't know how bad the performance regression is, and how large the
>>> integrity risk is.  I'd default towards preserving integrity, but maybe
>>> this situation is different.
>> I have reports of installations taking like 50 min instead of 14 min. My
>> own qemu-io based test goes up from 1 s to 23 s. And I think the winner
>> is Michael's image conversion which went up from 30 s to 49 min.
>>
>> So it's not like we're talking about just some 10 or 20 percent.
> 
> Image conversion should be done with cache=unsafe (with an fsync at the 

Well, should, but is not. Arguably we should improve our format drivers
to make the metadata flushes less of a problem, too. But we haven't done
so yet. This is why this discussion is about 0.13, not 0.14.

> end to make sure a guest isn't launched with volatile data in the 
> cache[1]).  The io test isn't a user workload.
> 
> The 14 min -> 50 min regression is pretty bad, but I'm not sure it's bad 
> enough to merit risking user data.

Without a disk write cache (or with a battery-backed one) cache=none is
safe without any additional flushes. So yes, users need to be aware of
the meaning of cache options. But they already had to be aware of it
with 0.12.

However, it might trap users who are not aware of it, which is why we
even have this discussion. It's not an easy question.

> [1] or better, when launching a guest with cache!=unsafe start with an 
> fsync to make sure it's on disk.

Hm, that's an interesting idea, never thought of that. Might make sense.

Kevin