qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write


From: Alexander Graf
Subject: Re: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"
Date: Tue, 24 Aug 2010 13:56:20 +0200
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Kevin Wolf wrote:
> Am 24.08.2010 13:02, schrieb Stefan Hajnoczi:
>   
>> On Tue, Aug 24, 2010 at 11:40 AM, Kevin Wolf <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]