Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend

[Paolo Bonzini <pbonzini@redhat.com>]

Il 06/09/2012 12:07, Kevin Wolf ha scritto:
>> The AIOCB is already invalid at the time the callback is entered, so we
>> could release it before the call.  However, not all implementation of
>> AIO are ready for that and I'm not really in the mood for large scale
>> refactoring...
> 
> But the way, what I'd really want to see in the end is to get rid of
> qemu_aio_flush() and replace it by .bdrv_drain() callbacks in each
> BlockDriver. The way we're doing it today is a layering violation.

That's quite difficult.  Completion of an I/O operation can trigger
another I/O operation on another block device, and so on until we go
back to the first device (think of a hypothetical RAID-5 device).

> Doesn't change anything about this problem, though. So the options that
> we have are:
> 
> 1. Delay the callback using a BH. Doing this in each driver is ugly.
>    But is there actually more than one possible callback in today's
>    coroutine world? I only see bdrv_co_io_em_complete(), which could
>    reenter the coroutine from a BH.

Easy and safe, but it feels a bit like a timebomb.  Also, I'm not
entirely sure of _why_ the bottom half works. :)

> 2. Delay the callback by just calling it later when the cleanup has
>    been completed and .io_flush() can return 0. You say that it's hard
>    to implement for some drivers, except if the AIOCB are leaked until
>    the end of functions like qcow2_create().

... which is what we do in posix-aio-compat.c; nobody screamed so far.

Not really hard, it just has to be assessed for each driver separately.
 We can just do it in gluster and refactor it later.

> 3. Add a delay only later in functions like bdrv_drain_all() that assume
>    that the request has completed. Are there more of this type? AIOCBs
>    are leaked until a bdrv_drain_all() call. Does it work with draining
>    specific BDSes instead of everything?
> 
> Unless I forgot some important point, it almost looks like option 1 is
> the easiest and safest.

I agree with your opinion, but I would feel better if I understood
better why it works.  (2) can be done easily in each driver (no
ugliness) and refactored later.

Paolo