Re: [PATCH] add support for vectored and async I/O to all simple filesystems

[Jamie Lokier <jamie@shareable.org>]

Anton Altaparmakov wrote:
> Yes, of course aio can block and in fact will block arbitrarily for 
> arbitrary lengths of time.  At least at present the implementations of 
> ->aio_read and ->aio_write in the file systems will block left right and 
> center.
>
> [examples...]

That's a shame.  I was hoping it would offer similar properties to
non-blocking I/O on sockets: something which can indicate that the
resource is unavailable, but allows the application to continue with
other things without needing parallel threads for that.

> The only way you can _really_ have guaranteed async io is to queue the io 
> to a kernel thread work queue and return immediately to the caller.  The 
> only thing you will then block on potentially is allocating memory for the 
> "queue entry item" and on waiting for the lock to the "queue" so it is 
> safe to write to it.

Since threads with well-defined blocking points can be mechanically
transformed to state machines, it is possible to guarantee async I/O
without needing extra threads.  I had wondered if the Linux AIO
implementation did something like that.

However, it is too complex to convert all filesystem code from
blocking to state machines (by hand), and unnecessary.  I've thought
about possible AIO implementations many times, and always return to
the idea of having AIOs be state machines which are handled
synchronously and by interrupts, up until a point where a complex
blocking point is reached in a filesystem (which shouldn't happen for
the common read/write cases, but may happen for the uncommon ones),
and then the AIOs convert to work handled by a worker thread spawned
from a pool on demand.

In other words, there are plenty of ways to guarantee properly async
I/O.  I'm surprised Linux AIO isn't - that seems to defeat the whole
point of AIO.

-- Jamie