On 10/24/2011 11:53 AM, Kevin Wolf wrote:
>> >
>> > I'm talking about the internal driver API only. The external API is
>> > fine as is.
> Ok, so external callers don't force us to do it.
>
> Yes, we could split bdrv_flush internally into two functions for "flush
> one level to the OS" and "f
Am 24.10.2011 11:40, schrieb Paolo Bonzini:
> On 10/24/2011 11:36 AM, Kevin Wolf wrote:
You're changing the API and asking for possibly non-trivial changes in
all protocol drivers, in order to accomodate semantics that all format
drivers potentially could desire. So I wonder if t
On 10/24/2011 11:36 AM, Kevin Wolf wrote:
> You're changing the API and asking for possibly non-trivial changes in
> all protocol drivers, in order to accomodate semantics that all format
> drivers potentially could desire. So I wonder if the problem is simply
> that the current API is not e
Am 24.10.2011 11:26, schrieb Paolo Bonzini:
> On 10/24/2011 10:54 AM, Kevin Wolf wrote:
>>> 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
On 10/24/2011 10:54 AM, Kevin Wolf wrote:
> 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 ren
On 24 October 2011 09:17, Kevin Wolf wrote:
> Am 24.10.2011 09:53, schrieb Paolo Bonzini:
>> 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, q
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
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'
Am 24.10.2011 09:53, schrieb Paolo Bonzini:
> On 10/24/2011 09:37 AM, Kevin Wolf wrote:
>>> Why? cache=unsafe is explicitly allowing to s/data/manure/ on
>>> crash.
>>
>> It's surely expected on a host crash, but is it for a qemu crash?
>> cache=unsafe was introduced to avoid fsync() costs, which i
Am 23.10.2011 16:33, schrieb Paolo Bonzini:
> On 10/22/2011 05:07 PM, Alexander Graf wrote:
>>
>> On 21.10.2011, at 11:44, Paolo Bonzini wrote:
>>
>>> On 10/21/2011 07:08 PM, Kevin Wolf wrote:
Avi complained that not even writing out qcow2's cache on
bdrv_flush() made cache=unsafe too uns
On 10/24/2011 09:37 AM, Kevin Wolf wrote:
Why? cache=unsafe is explicitly allowing to s/data/manure/ on
crash.
It's surely expected on a host crash, but is it for a qemu crash?
cache=unsafe was introduced to avoid fsync() costs, which it still
does after this patch.
I think it's not about "wh
Am 21.10.2011 20:44, schrieb Paolo Bonzini:
> On 10/21/2011 07:08 PM, Kevin Wolf wrote:
>> Avi complained that not even writing out qcow2's cache on bdrv_flush() made
>> cache=unsafe too unsafe to be useful. He's got a point.
>
> Why? cache=unsafe is explicitly allowing to s/data/manure/ on crash.
On 10/22/2011 05:07 PM, Alexander Graf wrote:
On 21.10.2011, at 11:44, Paolo Bonzini wrote:
On 10/21/2011 07:08 PM, Kevin Wolf wrote:
Avi complained that not even writing out qcow2's cache on
bdrv_flush() made cache=unsafe too unsafe to be useful. He's got
a point.
Why? cache=unsafe is expl
On 21.10.2011, at 11:44, Paolo Bonzini wrote:
> On 10/21/2011 07:08 PM, Kevin Wolf wrote:
>> Avi complained that not even writing out qcow2's cache on bdrv_flush() made
>> cache=unsafe too unsafe to be useful. He's got a point.
>
> Why? cache=unsafe is explicitly allowing to s/data/manure/ on cr
On 10/21/2011 07:08 PM, Kevin Wolf wrote:
Avi complained that not even writing out qcow2's cache on bdrv_flush() made
cache=unsafe too unsafe to be useful. He's got a point.
Why? cache=unsafe is explicitly allowing to s/data/manure/ on crash.
If you do this for raw-posix, you need to do it for
Avi complained that not even writing out qcow2's cache on bdrv_flush() made
cache=unsafe too unsafe to be useful. He's got a point.
Kevin Wolf (2):
raw-posix: Convert to bdrv_co_flush
block: Handle cache=unsafe only in raw-posix/win32
block.c |4 +--
block/raw-posix.c | 57 ++
16 matches
Mail list logo
