Re: [Qemu-devel] [PATCH] qcow2: Bring synchronous read/write back to life

[Anthony Liguori <anthony@codemonkey.ws>]

Kevin Wolf wrote:
> Am 08.10.2009 16:30, schrieb Anthony Liguori:
>   
>> Kevin Wolf wrote:
>>     
>>> When the synchronous read and write functions were dropped, they were replaced
>>> by generic emulation functions. Unfortunately, these emulation functions don't
>>> provide the same semantics as the original functions did.
>>>
>>> The original bdrv_read would mean that we read some data synchronously and that
>>> we won't be interrupted during this read. The latter assumption is no longer
>>> true with the emulation function which needs to use qemu_aio_poll and therefore
>>> allows the callback of any other concurrent AIO request to be run during the
>>> read.
>>>       
>> Perhaps you could create a mechanism to freeze the qcow2 image by 
>> queuing all completions within qcow2 until the image was unfrozen.  This 
>> would have the same effect switching to synchronous read/write.
>>
>> You may also have to queue new read/write requests...
>>
>> Introducing sync read/write seems like a major step backwards to me.
>>     
>
> Right, I was expecting your reaction. ;-) I do even agree that it's not
> nice to have the synchronous functions back. But removing them caused a
> regression, so the removal should be reverted until it is done right.
>
> I just want to make clear that we're talking about data corruption here.
> This is not just something that we can care about when we are bored some
> time in the future.
>   

Yeah, okay.  Can we do a more direct revert though so that it's clearer 
in the commit log?

> By the way, I don't think queuing things in qcow2 is the right thing to
> do. It probably wouldn't even help if, say, VMDK implemented AIO and I
> used a VMDK image as a backing file for qcow2. The real solution is to
> fix the generic bdrv_read/write emulation. Now we just need to find the
> best way to do this.
>   

Ideally, you could say qemu_aio_wait(aiocb) and it would only wait for 
that particular request.  I'm not convinced though that there aren't 
dependency issues though since we can generate synthetic aiocbs.

Regards,

Anthony Liguori