qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
Date: Mon, 24 Oct 2011 10:54:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

Am 24.10.2011 10:47, schrieb Paolo Bonzini:
> On 10/24/2011 10:17 AM, Kevin Wolf wrote:
>>>  I think it's not about "why is it there", but rather about "what is it
>>>  useful for".  My interpretation of it is "I do not need the image
>>>  anymore unless the command exits cleanly": VM installations, qemu-img
>>>  conversions, BDRV_O_SNAPSHOT (doesn't do it yet, but it could).  Even
>>>  SIGINT and SIGTERM would be excluded from this definition, but they cost
>>>  nothing so it's nice to include them.
>>
>> I think another common interpretation is: "I don't run this VM in
>> production but for development. I want the VM to go faster and I can
>> recreate the image in the unlikely event that power fails during my
>> work. But it certainly would be nasty."
> 
> Fair enough.
> 
>> But I think that starting to make exceptions for single block drivers
>> isn't a good idea anyway. If we want bdrv_flush() to write out all
>> metadata internal to qemu, I think the approach with checking the flag
>> in drivers calling things like fsync() is better. The common thing is to
>> do the flush.
> 
> I don't know... checking BDRV_O_NO_FLUSH in the drivers rather than in 
> the generic code sounds like a layering violation.  Perhaps what you're 
> after is a separation of bdrv_co_flush from bdrv_{,co_,aio_}fsync?  Then 
> BDRV_O_NO_FLUSH (better renamed to BDRV_O_NO_FSYNC...) would only 
> inhibit the latter.

Why? All other cache related BDRV_O_* flags are interpreted by the block
drivers, so why should BDRV_O_NO_FLUSH be special?

Kevin



reply via email to

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