linux - Linux内核AIO，开放系统调用

Question

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

Answer 1

首先，这是一个非常好的和合理的问题；不幸的是，它可能会推开比我知识渊博的人。

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

• 是的，网络服务器将受到网络延迟的约束。是否应该成为不关心所有其他 IO 的理由有点令人怀疑，但我可以接受。

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

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

• 然后是所有其他用例。对于包括 GUI 编程在内的许多人来说，我们有时或经常阻塞并不重要；我们永远不应该阻止。如果访问模式在时间上非常随机且距离很远，那么购买更多 RAM 也无济于事——缺少与二级存储提供的容量一样多的容量。

  “无论如何都应该快”的想法也是错误的；总是考虑远程文件系统。

唯一令人信服的一点是：

简短而甜蜜：“aio_open()”基本上不应该是一个问题。如果是这样，那么您设计了错误的东西，或者您太努力地尝试将所有内容单线程化（并且通过将其称为“AIO”来“隐藏” 确实发生的线程 - 简而言之，对自己撒谎）。

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

在同一个讨论中挖掘，你可以找到 Mikulas Patocka 的这篇文章：

您可以使用 FreeBSD 和一些商业 Unices 等内核线程模拟异步 IO，但您仍然需要与所服务的请求一样多的（可能是内核）线程。

(...)

制作真正的异步 IO 需要重写所有文件系统和整个 VFS _from_scratch_。它不会发生。

http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0074.html

这听起来像是一个正确的解释，但显然不是一个好的解释。

请记住，这是一个旧线程，从那时起发生了很多变化，所以这个答案没有什么价值。但是，它提供了关于为什么历史aio_open上无法获得假设的洞察力。此外，要了解许多内核讨论（或任何项目的任何内部讨论）通常期望所有参与者从大量假设开始。因此，我完全有可能没有以正确的方式看待这个问题。

话虽如此，这一点很有趣（Stephen C. Tweedie）：

啊，但即使是 VMS SYS$QIO 在执行打开、分配 IO 请求数据包以及将文件位置映射到磁盘块时也是同步的。只有数据 IO 是异步的（Ben 的 Linux 异步 IO 也提供了这一点）。

http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0139.html

为什么有趣？因为它强化了许多不同系统不会open异步实现（和其他调用）的概念。此外，aio_openPOSIX 没有指定，我找不到解释原因的讨论。Windows 似乎也忽略了这个问题。

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

我的猜测是这只是低优先级，而且一直如此。对于足够多的用于提供功能的用例来说，包括预先处理或打开文件的变通方法被认为是足够的，这永远不会被证明是合理的。

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

如果您想深入了解这一点，我怀疑您必须将讨论带到更合适的渠道，例如 LKML。

Answer 2

我编写了一个相当简单但功能强大的 cpaio C 实用程序，它使用 Linux 原生 aio+O_DIRECT（io_submit、io_getevents）复制一堆文件。我只是让它尽可能早地打开文件，对初始 aio 读取进行排队，并且只在打开足够多的文件（或者如果足够少，则全部打开）后才费心寻找读取的结果。有一种异步打开文件的方法会很好，但最终这没什么大不了的。
我已经用这个工具复制了几十 TB。
最后，我认为没有异步打开是有道理的。这是一个复杂的操作，内核基本上必须触发一个线程来处理它。