Linux内核AIO，开放系统调用

为什么Linux内核AIO不支持异步“开放”系统调用？ 因为“open”可以在文件系统上阻塞很长时间，不是吗？

首先，这是一个非常好且合理的问题；否决票是不幸的，它可能赶走了比我更有知识的人

事实上，没有充分的理由。您设法挖掘的讨论是相关的，但一点也不令人满意（这可能也是您的结论）。虽然Torvald的观点在技术上是正确的，但他们显然忽略了房间里的大象——GUI编程——以及我确信的许多其他用例

• 是的，网络服务器将受到网络延迟的限制。这是一个有点可疑的理由不关心所有其他IO，但我可以接受这一点

• 是的，许多服务器工作负载将能够使用dentry/inode缓存，但不是全部，而且总是会出现未命中

• 是的，“购买更多内存”的论点是有效的。我从来没有发现这是一个好的论点

• 还有其他所有的用例。对于许多人来说，包括GUI编程，我们有时阻塞或大量阻塞并不重要；我们永远不应该阻止，永远。如果访问模式在时间上是非常随机和遥远的，那么购买更多的RAM也无济于事——没有辅助存储提供的容量
  “无论如何都应该快”的想法也是错误的；始终考虑远程文件系统。

唯一引人注目的一点是：

简短而甜蜜：“aio_open（）”基本上不应该是一个 问题如果是，那就是你设计错了，或者你也在尝试 他妈的很难单线程所有的东西（和“隐藏”线程，那是什么 发生这种情况时，只需将其称为“AIO”——简言之，就是对自己撒谎）

这里的要点正是为了避免线程，所以这句话让我很惊讶。甚至列举了其他论点，这一事实向我表明，这一论点太脆弱，无法独立存在

在同样的讨论中，你可以找到Mikulas Patocka的这篇文章：

您可以使用诸如FreeBSD和 有些商业Unice是这样做的，但您仍然需要尽可能多的Unice（可能） 内核）处理您正在处理的请求的数量

（……）

制作真正的异步IO需要重写所有文件系统和 整个VFS从零开始。这不会发生的

这听起来是一个恰当的解释，但显然不是一个好的解释。

请记住，这是一个古老的线索，从那时起有很多变化，所以这个答案没有什么价值。然而，它提供了关于为什么历史上没有一个假设的

aio_open

的见解。另外，要了解许多内核讨论（或任何项目的内部讨论）通常期望所有参与者都从一系列假设开始。因此，我完全有可能没有正确看待这一点

话虽如此，这一点很有趣（斯蒂芬C.特维迪）：

啊，但即使是VMS SYS$QIO也在做开放时是同步的，分配 IO请求数据包，并将文件位置映射到磁盘块。只有 数据IO永远是异步的（Ben的Linux异步IO提供了 那也一样）

为什么很有趣？因为它强化了一个概念，即许多不同的系统不会异步实现

open

（和其他调用）。此外，

aio_open

不是POSIX指定的，我找不到解释原因的讨论。Windows似乎也忽略了这个问题

这就好像这个概念中有某种固有的东西是错误的或困难的，除了似乎没有人能很好地解释为什么最终会这样

我猜这只是低优先级，而且一直都是。包括预先线程化或打开文件在内的变通方法被认为足以满足提供该功能的足够用例的需要

了解POSIX为什么不定义这样一个调用会很有趣。不过，我希望有一个“超出范围”的理由

---

如果您想弄清这一点，我想您必须将讨论带到更合适的渠道，例如LKML。

我编写了一个相当简单但功能强大的cpaio C实用程序，它使用Linux本机aio+O_DIRECT（io_submit，io_getevents）复制大量文件。我只是让它尽可能早地打开文件，对初始aio读取进行排队，并且只在它打开足够多的文件（或者如果文件足够少的话，则查找所有文件）后才去查找读取结果。如果有一种异步打开文件的方法会很好，但最终这并不是什么大问题。
我用这个工具复制了数十TB。

---

最后，我认为不使用async open是有意义的。这是一个复杂的操作，内核必须启动一个线程来处理它。

没有初始研究的痕迹。这没有意义。即使使用

O_NONBLOCK

打开

，也需要
select
或一些轮询机制来查看文件是否已准备好进行I/O。否则，您可能只会将可能永远不会成功的AIO R/W请求排入队列。如果需要并发性，请生成另一个线程来
打开文件，或者继续为其他I/O操作提供服务。我的意思是仅Linux内核AIO（异步）。我不需要select、epoll等。我设法从Linus那里找到了非常古老的解释