有害的 USB 记忆棒失速问题- LWN.net，2013。
将慢速存储设备（比如 USB 记忆棒或媒体播放器）插入 Linux 机器并向其中写入大量数据。整个系统继续挂起，可能持续几分钟。
这篇文章预测了对内核默认值的简单更改。在 64 位 x86 上，默认情况下允许回写缓存增长到系统 RAM 的 20%。Linus 建议在所有平台上有效地将其限制为 ~180MB，模仿 32 位 x86 代码的限制。但是，当前的 Linux (v4.18) 不包括建议的更改。（将Linus 的 patch与v4.18中的当前函数进行比较）。
2013 LWN 文章称该问题是“相当于缓冲膨胀问题的存储”。现在有一篇 2016 LWN 文章介绍了一个新的 Linux 特性，称为 writeback throttling ( wbt/ CONFIG_WBT/ wbt_lat_usec)。这篇文章将写回限制描述为一种缓解“反映网络堆栈中出现的问题的缓冲区膨胀问题”的方法。这听起来非常相似:-)。
现在是否解决了特定的 U 盘失速问题？
走向不那么烦人的背景写回- LWN.net，2016
这是我们很多人都有过的经历：将一堆数据写入一个相对较慢的块设备，然后尝试完成一些其他工作。在许多情况下，系统会缓慢爬行，甚至会出现一段时间的冻结；在大量数据写入设备之前，事情不会恢复。在具有大量内存和缓慢 I/O 设备的系统上，将事物恢复到可工作状态可能需要很长时间，有时以分钟为单位。Linux 用户对这种行为模式不以为然，这是可以理解的，但它已经顽固地存在了很长时间。现在，也许，一个新的补丁集会改善这种情况。
受此问题启发：System lags when doing large R/W operations on external disks
问题是“U 盘失速”文章没有为其说法提供证据。出现了真正的“U盘失速”问题，并且不断有一些类似的报道。但是 LWN 文章讨论的线程不是其中之一！因此，我们不能引用这篇文章作为例子。此外，它给出的任何解释都必须是有缺陷的，或者至少是不完整的。
为什么在 2013 年报告了“U 盘失速”问题？为什么现有的“No-I/O 脏节流”代码没有解决这个问题？
总结链接的答案：
报告给 linux-kernel 的问题没有看到整个系统挂起，而它正在将缓存的写入刷新到 USB 记忆棒。Artem 最初的报告只是抱怨 Linux 允许在慢速设备上进行大量缓存写入，这可能需要“数十分钟”才能完成。
正如您所说，Linus 建议的“修复”尚未应用。当前的内核版本（v4.20 及以下）仍然允许具有大 RAM 的系统在页面缓存中构建大量写入，这可能需要很长时间才能写出。
内核已经有一些旨在避免“USB 记忆棒停顿”的代码。这是“无 I/O 脏节流”代码。2011 年，LWN 上也描述了此代码。它限制 write() 调用以控制整体回写缓存的大小以及用于特定支持设备的回写缓存的比例。这是一个复杂的工程系统，随着时间的推移已经过调整。我相信它会有一些限制。到目前为止，我无法量化任何限制。在肮脏的节流代码之外还有各种错误修复，以解决阻止其工作的问题。
WBT 限制每个单独设备提交的IO 请求的数量。它不限制写回缓存，即脏页缓存。
Artem 发布了一份后续报告，称将 10GB 写入服务器的内部磁盘会导致系统挂起，或者至少会遭受极长的响应延迟。 这与 WBT 旨在解决的问题是一致的。
此答案的先前版本中保留的旁注：
WBT 描述的场景是当您将大量数据写入主磁盘，同时您希望继续以交互方式使用主磁盘，加载程序等。
相反，当人们谈论“U盘卡顿”问题时，他们的意思是将大量数据写入不同的磁盘/外部USB等，然后在与该磁盘无关的程序中遭受令人惊讶的延迟。例子：
“即使是像移动窗口这样简单的事情也可能会卡顿......这不是 CPU 负载，因为与远程机器的 ssh 会话完全响应；相反，似乎任何可能模糊地接近执行文件系统 IO 的东西都被严重延迟了。”
2013 年关于 USB 记忆棒问题的邮件列表线程提到了对脏页缓存的每个设备限制作为未来工作的可能性。
WBT 不适用于 CFQ 或 BFQ IO 调度程序。Debian 和 Fedora 默认使用 CFQ，因此 WBT 对 U 盘（或旋转硬盘）没有帮助，除非您有一些特殊配置。
传统上，CFQ 已被用于与旋转硬盘驱动器一起工作。我不完全确定这会将 WBT 留在哪里。也许 WBT 的主要优势在于 SSD，它比旋转硬盘驱动器更快，但太慢而不能像 RAM 一样对待？
或者也许它是使用
deadline调度程序而不是 CFQ 功能的一个论点。Ubuntu 切换到deadline版本 14.04，但从版本 17.04 (zesty)切换回 CFQ 。（我认为 CentOS 7.0 太旧了，不能有 WBT，但它声称对 SATA 驱动器和deadline所有其他驱动器使用 CFQ。CentOS 7.0 也支持 NVMe 驱动器，但只显示“无”为其调度程序。）