Linux内核AIO，开放系统调用 [英] Linux kernel AIO, open system call

问题描述

为什么Linux Kernel AIO不支持异步开放"系统调用? 因为打开"会长时间阻塞文件系统，所以不能吗?

Why Linux Kernel AIO does not support async 'open' system call? Because 'open' can block on filesystem for long time, cant it?

推荐答案

首先，这是一个完全正确且合理的问题；不幸的事是不幸的，它可能使人们比我更了解我.

AFAICT，没有好原因.您设法进行的讨论是相关的，但根本不令人满意(这也可能是您的结论).尽管Torvald的观点在技术上是正确的，但它们显然忽略了会议室中的大象-GUI编程-以及我确定的许多其他用例.

AFAICT, there is no good reason. The discussion you managed to dig up is relevant, but not satisfactory at all (which is probably your conclusion as well). Though Torvald's points are technically correct, they clearly dismiss the elephant in the room -- GUI programming -- as well as many other use-cases I'm sure.

• 是的，网络服务器将受到网络延迟的限制.值得怀疑的是，它不关心所有其他IO，但我可以接受.

• Yes, network servers will be bound by network latency. It's a bit dubious that it should be a reason not to care about all other IO, but I can accept that.

是的，许多服务器工作负载将能够利用dentry/inode缓存，但不是全部，并且总是会丢失.

Yes, many server workloads will be able to make use of the dentry/inode cache, but not all, and there will always be misses.

是的，参数购买更多RAM"有效.我从来没有发现这是一个很好的论点.

Yes, the argument "buy more RAM" works. I've never found it to be a good argument.

然后是所有其他用例.对于许多人，包括GUI编程，我们有时会阻塞很多也不会阻塞；我们永远都不会阻止.如果访问模式非常随机且时间间隔很远，那么购买更多的RAM也无济于事-缺少与二级存储所提供的容量一样的容量.

And then there's all the other use-cases. For many, including GUI programming, it doesn't matter that we block sometimes or a lot; we should never block, ever. If the access patterns are very random and distant in time, buying more RAM won't help either -- short of having as much capacity as what the secondary storage offers.

无论如何都应该快"的想法也是错误的.始终考虑使用远程文件系统.

The idea that "it should be fast anyway" is also wrong; always consider remote filesystems.

唯一引人注目的是:

又简短又甜蜜:基本上从不应该将"aio_open()"视为 问题.如果是这样，则说明您设计错误，或者您也尝试过 很难对所有内容进行单线程处理(并隐藏"该线程 确实是通过将其称为"AIO"来实现的-简而言之，对自己撒谎).

Short and sweet: "aio_open()" is basically never supposed to be an issue. If it is, you've misdesigned something, or you're trying too damn hard to single-thread everything (and "hiding" the threading that does happen by just calling it "AIO" instead - lying to yourself, in short).

这里的重点恰恰是避免线程化，因此这一说法令我感到惊讶.甚至列举了其他论点的事实也向我表明，这一论点太脆弱了，无法独立存在.

The point here is precisely to avoid threading, so this remark surprised me. The mere fact that the other arguments were even enumerated suggests to me that this one is too fragile to stand on its own.

在同一讨论中四处浏览，您可以找到Mikulas Patocka的这篇文章:

Digging around in the same discussion, you can find this post by Mikulas Patocka:

您可以使用FreeBSD和 一些商业Unices可以，但是您仍然需要那么多(可能 内核)处理尽可能多的正在处理的请求.

You can emulate asynchronous IO with kernel threads like FreeBSD and some commercial Unices do, but you still need as many (possibly kernel) threads as many requests you are servicing.

(...)

制作真正的异步IO将需要重写所有文件系统，并且 整个VFS _from_scratch_.不会发生的.

Making real async IO would require to rewrite all filesystems and whole VFS _from_scratch_. It won't happen.

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

这听起来像是一个恰当的解释，尽管显然不是一个很好的解释.

请记住，这是一个旧线程，此后发生了很多变化，因此此答案的价值很小.但是，它提供了关于为什么历史上无法获得假设的aio_open的见解.另外，请理解，许多内核讨论(或与此相关的任何项目的任何内部讨论)通常都希望所有参与者都从大量的假设开始.因此，很有可能我没有以正确的方式看待这个问题.

Keep in mind this is an old thread and a lot has changed since then, so this answer has very little value. However, it provides insight as to why a hypothetical aio_open wasn't available historically. Also, understand that many kernel discussions (or any internal discussion for any project for that matter) usually expect that all participants start with a large set of assumptions. It's thus entirely possible that I'm not looking at this the right way.

话虽如此，这一点很有趣(斯蒂芬·C·特威迪):

That being said, this bit is interesting (Stephen C. Tweedie):

啊，但是VMS SYS $ QIO在打开时也是同步的，分配 IO请求数据包，并将文件位置映射到磁盘块.仅有的 数据IO一直是异步的(而Ben的Linux异步IO东西提供了 也是如此).

Ahh, but even VMS SYS$QIO is synchronous at doing opens, allocation of the IO request packets, and mapping file location to disk blocks. Only the data IO is ever async (and Ben's async IO stuff for Linux provides that too).

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

为什么有趣?因为它强化了这样的观念，即许多不同的系统不会异步实现open(和其他调用).此外，POSIX未指定aio_open，因此无法找到解释原因的讨论. Windows似乎也忽略了这个问题.

Why is it interesting? Because it reinforces the notion that a lot of different systems don't implement open (and other calls) asynchronously. Furthermore, aio_open is not specified by POSIX, and I cannot find discussions explaining why. Windows also seems to ignore the issue.

这个概念似乎有一些内在的错误或困难，除非似乎没有人为这到底是为什么提供充分的理由.

It's as if there was something inherent to the concept that is wrong or difficult, except nobody seems to make a good case for why that is in the end.

我的猜测是，这只是低优先级，而且一直如此.预先包含线程或打开文件的变通办法对于足以提供功能的用例来说，已经足够了.

My guess is this is simply low-priority, and always has been. Workarounds that include threading or opening files beforehand are supposedly sufficient for enough use-cases that work to provide the functionality could never be justified.

了解为什么POSIX没有定义这样的调用会很有趣.我预计会有超出范围"的理由.

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

If you want to get to the bottom of this, I suspect you'll have to bring the discussion to more appropriate channels, such as LKML.

这篇关于Linux内核AIO，开放系统调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！