[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qcow2: Bring synchronous read/write back to lif
Re: [Qemu-devel] [PATCH] qcow2: Bring synchronous read/write back to life
Thu, 08 Oct 2009 10:01:13 -0500
Thunderbird 220.127.116.11 (X11/20090825)
Kevin Wolf wrote:
Am 08.10.2009 16:30, schrieb Anthony Liguori:
Kevin Wolf wrote:
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.
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
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.