Kevin, --On 1 July 2013 12:23:53 +0200 Kevin Wolf <kw...@redhat.com> wrote:
"inject-error" doesn't really describe this well. Shouldn't we rather introduce a new section "[delay]" or something like that?
That's how I started off. Then I realised you might want to make the delay dependent on the sector or state, or the operation concerned. Changing the name of the section to '[inject]' would probably be best.
I remember that I once tried something similar, but never submitted it. I think the reason was that using timers inside requests doesn't really work. It works as long as everything is indeed asynchronous, but bdrv_drain_all() or a loop waiting for a single request that tries to make progress with qemu_aio_wait() will simply hang because timers aren't processed in these nested event loops.
Yes I discovered that the hard way. In particular, timers are not run at all in (e.g.) qemu-img. I think they are not run at all outside qemu itself. This is why I don't use timers. What it currently does is schedule a bh which looks at the time (as time still moves forwards) - using idle scheduling, and if it's not time to run the bh, the bh reschedules itself (using idle scheduling again). Because of the use of idle scheduling it isn't busy-waiting, but it is hardly ideal. I /think/ this is safe because if bh's aren't running, lots of drivers (e.g. blkverify) would not work. And as far as I can tell, idle bh's are scheduled whenever non-idle ones are. However, I am newbie as far as the async code and the block code are concerned. -- Alex Bligh