Linux中的写请求流是从用户空间到设备吗？

Question

我对在Linux中从用户空间发出write命令时会发生什么感到困惑。向下到存储设备的完整流程是什么？假设我使用CFQ和一个仍然使用pdflush的内核。

据说CFQ将请求放入同步和a-sync队列中。例如，写入是a-sync，因此它们根据io优先级进入a-sync队列。队列将根据CFQ时间片、过期设置等获取CPU。

同时，写入脏页。写脏页由VM设置触发，并在pdflush线程的上下文中完成，该线程运行调用writeback_nodes()的background_writeout()的副本。当发生这种情况时，pdflush的写入肯定是同步的。

这是否意味着对于相同或相似的写请求，我们可能会有两个相互竞争的写操作-一个由CFQ队列机制控制，另一个由VM子系统触发？

这是否意味着只要我们点击dirty_background_ratio，VM子系统就会有效地破坏CFQ规则，因为pdflush并不具有与请求进程相同的io优先级？

一旦我们点击dirty_ratio，CFQ设置就或多或少变得过时了，因为所有的写入都变得同步了？

我已经阅读了很多关于这两个子系统的具体信息，但我还不能理解整个写请求流程。交互式Linux内核映射不包括IO调度程序。

任何指向整个图片的指针都将不胜感激。

谢谢，亚历克斯

Answer 1

从那时起我就找到了它。基本上，是的，pdflush和写缓存通常会破坏写操作的IO优先级。读操作仍然可以从CFQ中受益，因为它们是同步的，并且同步请求具有优先级，但要使写操作受到IO优先级的影响，它们必须是直接的。