Am 03.06.2010 18:23, schrieb MORITA Kazutaka:
>>> +static void sd_aio_cancel(BlockDriverAIOCB *blockacb)
>>> +{
>>> + SheepdogAIOCB *acb = (SheepdogAIOCB *)blockacb;
>>> +
>>> + acb->canceled = 1;
>>> +}
>>
>> Does this provide the right semantics? You haven't really cancelled the
>> request, but you pretend to. So you actually complete the request in the
>> background and then throw the return code away.
>>
>> I seem to remember that posix-aio-compat.c waits at this point for
>> completion of the requests, calls the callbacks and only afterwards
>> returns from aio_cancel when no more requests are in flight.
>>
>> Or if you can really cancel requests, it would be the best option, of
>> course.
>>
>
> Sheepdog cannot cancel the requests which are already sent to the
> servers. So, as you say, we pretend to cancel the requests without
> waiting for completion of them. However, are there any situation
> where pretending to cancel causes problems in practice?
I'm not sure how often it would happen in practice, but if the guest OS
thinks the old value is on disk when in fact the new one is, this could
lead to corruption. I think if it can happen, even without evidence that
it actually does, it's already relevant enough.
> To wait for completion of the requests here, we may need to create
> another thread for processing I/O like posix-aio-compat.c.
I don't think you need a thread to get the same behaviour, you just need
to call the fd handlers like in the main loop. It would probably be the
first driver doing this, though, and it's not an often used code path,
so it might be a bad idea.
Maybe it's reasonable to just complete the request with -EIO? This way
the guest couldn't make any assumption about the data written. On the
other hand, it could be unhappy about failed requests, but that's
probably better than corruption.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
