“写回限制”是解决“USB 存储卡停顿问题”的方法吗？

Question

问题是“U 盘失速”文章没有提供任何证据来证明其说法。确实存在“USB 棒失速”问题，并且不断有一些类似的报告。然而，LWN 文章讨论的主题并不是其中之一！因此我们不能引用这篇文章作为例子。此外，它给出的任何解释都必定是有缺陷的，或者至少是不完整的。

为什么 2013 年会出现“U 盘失速”问题？为什么现有的“无 I/O 脏节流”代码没有解决这个问题？

总结链接的答案：

向 linux-kernel 报告的问题确实不是当它正在将缓存的写入刷新到 USB 记忆棒时，会看到整个系统挂起。 Artem 的最初报告只是抱怨 Linux 允许在慢速设备上进行大量缓存写入，这可能需要“数十分钟”才能完成。

正如你所说，Linus 建议的“修复”尚未应用。当前的内核版本（v4.20 及更低版本）仍然允许具有大 RAM 的系统在页面缓存中建立大量写入，这可能需要很长时间才能写出。

内核已经有一些旨在避免“USB 记忆棒停顿”的代码。这是“无 I/O 脏节流”代码。 2011 年，LWN 上也对这段代码进行了描述。它通过限制 write() 调用来控制整体回写缓存的大小以及所使用的回写缓存的比例对于特定的支持设备。这是一个复杂的工程系统，随着时间的推移不断进行调整。我确信它会有一些限制。到目前为止我还无法量化任何限制。在肮脏的节流代码之外还修复了各种错误，以解决阻止其工作的问题。

WBT限制提交数量IO请求对于每个单独的设备。它不限制回写缓存，即脏的页面缓存。

Artem 发布了一份后续报告，称向服务器写入 10GB内部的磁盘导致系统挂起，或者至少在响应方面遭受极长的延迟。那与 WBT 旨在解决的问题是一致的。

本答案之前版本中保留的旁注：

WBT 描述的场景是当您将大量数据写入您的主要的磁盘，同时您希望继续以交互方式使用主磁盘来加载程序等。

相比之下，当人们谈论“USB 记忆棒失速”问题时，他们的意思是将大量数据写入不同的磁盘/外部 USB 等，然后在与该磁盘无关的程序中遭受令人惊讶的延迟。例子：

“即使像移动窗口这样简单的事情也可能会出现卡顿……这不是 CPU 负载，因为与远程计算机的 ssh 会话响应完美；相反，似乎任何可能隐约接近执行文件系统 IO 的操作都被严重延迟了。”

2013 年关于 USB 记忆棒问题的邮件列表主题，提到对脏页缓存的每设备限制作为未来工作的可能性。

WBT 不能与 CFQ 或 BFQ IO 调度程序一起使用。 Debian 和 Fedora 默认使用 CFQ，因此 WBT 对 USB 记忆棒（或旋转硬盘）没有帮助，除非您有一些特殊的配置。

传统上，CFQ 与旋转硬盘驱动器配合良好。我不太确定 WBT 会走向何方。也许 WBT 的主要优势在于 SSD，它比旋转硬盘更快，但太慢而无法像 RAM 一样处理？

deadline或者可能是使用调度程序并放弃 CFQ 功能的争论。 Ubuntu 切换到deadline 在 14.04 版本中，但切换回 CFQ 因为版本 17.04（热情）。（我认为 CentOS 7.0 太旧了，没有 WBT，但它声称对 SATA 驱动器以及deadline所有其他驱动器使用 CFQ。CentOS 7.0 也支持 NVMe 驱动器，但仅显示“没有任何“对于他们的调度程序。）

Answer 1