Anthony Liguori wrote:
IMHO it would be a much better idea to kill the aio interface altogether
and instead make the block drivers reentrant. Then you can use
(multiple) posix threads to run the I/O async if you want.
Threads are a poor substitute for a proper AIO interface. linux-aio
gives you everything you could possibly want in an interface since it
allows you to submit multiple vectored operations in a single syscall,
use an fd to signal request completion, complete multiple requests in a
single syscall, and inject barriers via fdsync.
I still think implementing async i/o at block driver level is the wrong
thing to do. You'll end up reinventing the wheel over and over again
and add complexity to the block drivers which simply doesn't belong
there (or not supporting async I/O for most file formats). Just look at
the insane file size of the block driver for the simplest possible disk
format: block-raw.c. It will become even worse when adding a
linux-specific aio variant.
In contrast: Making the disk drivers reentrant should be easy for most
of them. For the raw driver it should be just using pread/pwrite
syscalls instead of lseek + read/write (also saves a syscall along the
way, yea!). Others probably need an additional lock for metadata
updates. With that in place you can easily implement async I/O via
threads one layer above, and only once, in block.c.
IMHO the only alternative to that scheme would be to turn the block
drivers in some kind of remapping drivers for the various file formats
which don't actually perform the I/O. Then you can handle the actual
I/O in a generic way using whatever API is available, be it posix-aio,
linux-aio or slow-sync-io.