At Fri, 04 Jun 2010 13:04:00 +0200, Kevin Wolf wrote: > > 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. >
I agree. > > 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. > Completing with -EIO looks good to me. Thanks for the advice. I'll send an updated patch tomorrow. Regards, Kazutaka -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html