Linux 上的 POSIX AIO 和 libaio 之间的区别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8768083/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Difference between POSIX AIO and libaio on Linux?
提问by itisravi
What I seemto understand:
我似乎明白了什么：
POSIX AIOAPIs are prototyped in <aio.h>and you link your program with librt(-lrt), while the libaioAPIs in <libaio.h>and your program is linked with libaio (-laio).
POSIX AIOAPI 是原型，<aio.h>您将程序与 librt(-lrt) 链接，而您的程序中的libaioAPI<libaio.h>与 libaio (-laio) 链接。
What I can't figure out:
我想不通的是：
1.Does the kernel handle the either of these methods differently?
1.内核对这两种方法的处理方式不同吗？
2.Is the O_DIRECTflag mandatory for using either of them?
2.是否O_DIRECT必须使用其中任何一个标志？
As mentioned in this post, libaio works fine without O_DIRECTwhen using libaio.Okay,understood but:
正如这篇文章中提到的，libaio在不O_DIRECT使用的情况下工作正常。 好的libaio，理解但是：
According to R.Love's Linux System Programmingbook, Linux supports aio(which I assume is POSIX AIO) on regular files onlyif opened with O_DIRECT.But a small program that I wrote (using aio.h,linked with -lrt) that calls aio_writeon a file opened without the O_DIRECTflag works without issues.
据R.Love的Linux的系统编程的书，Linux支持AIO（我假设是POSIX AIO）在常规文件上只如果打开了O_DIRECT。但一个小程序，我写的（使用aio.h，与-lrt链接）的呼叫aio_write上没有O_DIRECT标志打开的文件没有问题。
采纳答案by Arvid
On linux, the two AIO implementations are fundamentally different.
在 linux 上，两种 AIO 实现根本不同。
The POSIX AIO is a user-level implementation that performs normal blocking I/O in multiple threads, hence giving the illusion that the I/Os are asynchronous. The main reason to do this is that:
POSIX AIO 是一个用户级实现，它在多个线程中执行正常的阻塞 I/O，因此给人一种 I/O 是异步的错觉。这样做的主要原因是：
- it works with any filesystem
- it works (essentially) on any operating system (keep in mind that gnu's libc is portable)
- it works on files with buffering enabled (i.e. no O_DIRECT flag set)
- 它适用于任何文件系统
- 它（基本上）适用于任何操作系统（请记住，gnu 的 libc 是可移植的）
- 它适用于启用缓冲的文件（即未设置 O_DIRECT 标志）
The main drawback is that your queue depth (i.e. the number of outstanding operations you can have in practice) is limited by the number of threads you choose to have, which also means that a slow operation on one disk may block an operation going to a different disk. It also affects which I/Os (or how many) is seen by the kernel and the disk scheduler as well.
主要缺点是您的队列深度（即您在实践中可以拥有的未完成操作的数量）受您选择拥有的线程数量的限制，这也意味着一个磁盘上的缓慢操作可能会阻止一个操作进入不同的磁盘。它还影响内核和磁盘调度程序看到的 I/O（或多少）。
The kernel AIO (i.e. io_submit() et.al.) is kernel support for asynchronous I/O operations, where the io requests are actually queued up in the kernel, sorted by whatever disk scheduler you have, presumably some of them are forwarded (in somewhat optimal order one would hope) to the actual disk as asynchronous operations (using TCQ or NCQ). The main restriction with this approach is that not all filesystems work that well or at all with async I/O (and may fall back to blocking semantics), files have to be opened with O_DIRECT which comes with a whole lot of other restrictions on the I/O requests. If you fail to open your files with O_DIRECT, it may still "work", as in you get the right data back, but it probably isn't done asynchronously, but is falling back to blocking semantics.
内核 AIO（即 io_submit() 等）是内核对异步 I/O 操作的支持，其中 io 请求实际上在内核中排队，按您拥有的任何磁盘调度程序排序，大概其中一些被转发（以某种希望的最佳顺序）到实际磁盘作为异步操作（使用 TCQ 或 NCQ）。这种方法的主要限制是，并非所有文件系统都能很好地工作或根本无法使用异步 I/O（并且可能会退回到阻塞语义），必须使用 O_DIRECT 打开文件，这对I/O 请求。如果您无法使用 O_DIRECT 打开文件，它可能仍然“工作”，因为您获得了正确的数据，但它可能不是异步完成的，而是退回到阻塞语义。
Also keep in mind that io_submit() can actually block on the disk under certain circumstances.
还要记住，io_submit() 在某些情况下实际上可以在磁盘上阻塞。
