Difference between POSIX AIO and libaio on Linux?

What I understand:

POSIX AIO APIs are prototyped in <aio.h> , and you link your program to librt (-lrt), and the libaio API in <libaio.h> and your program is linked to libaio (-laio).

What I can not understand:

1. Does the kernel handle one of these methods differently?

2.If the O_DIRECT flag O_DIRECT required to use any of them?

As mentioned in this post , libaio works fine without O_DIRECT when using libaio .Okay, understood, but:

According to the Linux programming book LLove Linux, Linux supports aio (which I assume is POSIX AIO) on regular files only if it is opened with O_DIRECT . But the little program I wrote (using aio.h related to -lrt) that calls aio_write in a file opened without the O_DIRECT flag, no problem.

+41
linux asynchronous io linux-kernel aio
Jan 07 '12 at 7:17
source share
1 answer

In linux, two AIO implementations are fundamentally different.

POSIX AIO is a user-level implementation that performs conventional blocking I / O on multiple threads, giving the illusion that I / O is asynchronous. The main reason is as follows:

  • it works with any file system
  • it works (essentially) on any operating system (keep in mind that gnu libc is portable)
  • it works with files with buffering enabled (i.e., the O_DIRECT flag is not set)

The main disadvantage is that your queue depth (that is, the number of outstanding operations that you can have in practice) is limited by the number of threads that you have selected, which also means that a slow operation on one disk can block the operation of switching to another disk. It also affects which I / O operations (or how many) are scanned by the kernel and disk planner.

The AIO kernel (i.e. io_submit () et.al.) is kernel support for asynchronous I / O operations, where io requests are actually queued in the kernel, sorted by any disk scheduler, apparently some of them (in some optimal order can be hoped for) on the actual disk in the form of asynchronous operations (using TCQ or NCQ). The main limitation of this approach is that not all file systems work as well or generally with asynchronous I / O (and can return to blocking semantics), files must be opened using O_DIRECT, which contains many other restrictions on I / O requests . If you cannot open your files with O_DIRECT, it can still "work" since you are getting the correct data back, but it probably does not execute asynchronously, but returns to blocking semantics.

Also keep in mind that io_submit () may actually lock onto disk under certain circumstances.

+51
Jan 08 '12 at 23:21
source share



All Articles