Kevin Wolf wrote: > Am 24.08.2010 13:02, schrieb Stefan Hajnoczi: > >> On Tue, Aug 24, 2010 at 11:40 AM, Kevin Wolf <kw...@redhat.com> wrote: >> >>> This reverts commit 8b3b720620a1137a1b794fc3ed64734236f94e06. >>> >>> This fix has caused severe slowdowns on recent kernels that actually do >>> flush >>> when they are told so. Reverting this patch hurts correctness and means >>> that we >>> could get corrupted images in case of a host crash. This means that qcow2 >>> might >>> not be an option for some people without this fix. On the other hand, I get >>> reports that the slowdown is so massive that not reverting it would mean >>> that >>> people can't use it either because it just takes ages to complete stuff. It >>> probably can be fixed, but not in time for 0.13.0. >>> >>> Usually, if there's a possible tradeoff between correctness and >>> performance, I >>> tend to choose correctness, but I'm not so sure in this case. I'm not sure >>> with >>> reverting either, which is why I post this as an RFC only. >>> >>> I hope to get some more comments on how to proceed here for 0.13. >>> >> Sometimes an improvement has a side effect and it makes sense to hold >> back the improvement until the side effect can be resolved. The >> period of time in which users could rely on qcow2 data integrity is >> small to none, I feel reverting the commit makes sense. >> > > Right, that's the vague feeling I have, too. >
If we don't think of qcow2 as integer format, why don't we just default to cache=unsafe there then? That way you could keep all the syncs in place making it stable with cache=!unsafe, but the default for users would be fast albeit unsafe, which it already is. Alex
