我想了解一下梅尔·戈尔曼 2013 年写的这封电子邮件：
https://lore.kernel.org/lkml/[电子邮件受保护]/
但仍然存在问题。如果所有脏页都由慢速设备支持，那么脏限制最终仍然会导致脏页平衡停滞。 [...] 有意识或无意识地，我的桌面应用程序通常不会遇到这些问题。 [...]当插入 U 盘时，我可能会无意识地避免进行任何写入量大的工作。
它建议采用以下方法。这有不是尚未实现，即在 Linux 5.1 中。
我仍然怀疑我们将不得不硬着头皮并使用每个 bdi 写回估计基于“不要弄脏超过 N 秒写回的数据”进行调整。实现起来并不是那么简单，因为写回速度可能会因各种原因（多个 IO 源、随机与顺序等）而改变。因此，在某一时刻，我们认为我们已经在目标窗口之内，但后来却完全错了。脏率是一个硬保证，脏写回估计是尽力而为，在某些情况下会出错。
电子邮件中提到的内核代码中的“突出问题”是什么？为什么戈尔曼期望看到现有代码停滞不前？
例如，我们是否知道它们是否会导致当代 PC 一次完全挂起超过 5-10 秒？或者，可能导致打开的窗口显示为挂起（同时仍然允许移动光标和移动窗口）？
电子邮件中是否有已知错误的部分？
现在的Linux内核还存在同样的问题吗？
我见过一些非常相似症状的报告，例如作者：Chris Siebenmann，2017 年。
梅尔·戈尔曼的电子邮件是存档讨论的一部分。 LWN.net 将讨论写为“有害的 USB 记忆棒停顿问题”。 请避免简单地模仿那篇文章。下面将对此进行讨论。
测试（“你尝试过什么？”）
我运行内核5.1.6-200.fc29.x86_64。我有一个 8G Imation USB 驱动器。 dd if=/dev/zero of=/var/run/media/alan/imation/test bs=1M status=progress收敛到大约 4MiB/s。即大约比我的主 HDD 所能达到的低 25 倍。目前运行它，grep -E 'Dirty|Writeback' /proc/meminfo在任何给定时间都会收敛到大约 1GiB 的缓存写入。我有 8GiB 物理 RAM。
（Writeback一次仅显示一或两个 MiB。另请注意，脏级别可能会有所不同。它过去被设置为 MemTotal（即物理 RAM）的近似比例。目前，脏级别被设置为 MemAvailable 的近似比例）。
在 USB 写入期间，我的系统保持响应。我可以移动窗口，我可以继续使用我的网络浏览器......
在 USB 写入之前和期间，我在主 HDD 上运行了以下延迟测试。两种情况花费的时间相同：大约 3-4 秒：
mkdir "$HOME"/tmp
cd "$HOME"/tmp
time bash -c "for (( i=0; i < 100; i++ )); do dd if=/dev/zero bs=16k count=1 of=latencytest status=none; sync latencytest; mv latencytest latencytest2; done"
“有害的 USB 记忆棒失速问题”——？
对于 LWN 来说，不同寻常的是，他们没有足够仔细地阅读。 LWN 关于此问题的文章将两个不同的问题混为一谈。我在以下链接中详尽地引用了这一主张。为了尽量减少读者的疲劳，我在下面挑选了相关细节。
为什么 2013 年会出现“U 盘失速”问题？为什么现有的“无 I/O 脏节流”代码不能解决这个问题？
存档的电子邮件讨论了由于建立了相应数量的“脏”（未写入）页面缓存而导致持续数秒的停顿。但对具体细节有些困惑。
这原始投诉很清楚。 Linus Torvalds 使用更具体的例子重申了这一抱怨。例如，将随机的 1GB 文件拖放linux.iso到已安装的 USB 闪存驱动器中。假设驱动器可以写入 10MB/s。您运行time sync将缓存的写入刷新到文件系统，您发现需要 100 秒。这感觉像是一个过大的写入缓存！
此结果取决于您是否拥有 8GB 或更多 RAM，以及 64 位内核。写入缓存限制为 RAM 的 20%。戏剧性的部分是，如果您比较 32 位内核，则限制仅根据前 1GB RAM 计算。因此，sync当您切换到 64 位内核时，您可能会看到该部分的等待时间延长了 8 倍（或 16 倍，或...）。我可以理解对此感到震惊和沮丧:-)。
A第二次投诉也被发布了。这是一个不同的“近失速”场景，其中涉及主系统盘仅有的。
第二种情况的机制更为复杂。它填满了主磁盘和主磁盘的内核 IO 调度程序内的请求队列。即使您不允许 20 秒或更长的“脏”缓存，您也可能会遇到问题。尽管两个问题之间存在一些重叠。
发现类似于第二种情况的问题似乎要容易得多。就停止系统而言，对我的/home或文件系统的持续写入似乎要危险得多（这包括防止或延迟切换到文本 VT，例如使用 Ctrl+Alt+F6）。/我最近看到了这个。最近较少：“每次克隆虚拟机映像时，我的系统的响应速度都会变得非常非常慢。”