在最近一次硬件迁移之后，我开始遇到奇怪的 I/O 停顿，影响我的桌面 Debian Stretch 系统。典型症状，都发生在每个摊位期间：
我无法与我的网络浏览器 Chromium 交互。没有任何效果：网页滚动（通常这是我注意到停顿的方式）、切换标签等。无论是在网页上还是在 Chromium UI 上，都没有鼠标悬停动作。
在虚拟终端中，我无法再运行新进程。例如，我在其中打开一个新选项卡，
mate-terminal但我的 shell 没有出现，只是光标在闪烁。在停止前打开 shell 的终端中，我可以输入命令，但通常它不会启动；sudo something甚至不要求输入密码。其他程序，如 RStudio，无法将任何内容保存到磁盘，并且在尝试保存时经常挂起。
我在日志中看到
journald -f，如果停顿时间足够长，journald它本身会重新启动，例如：sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Main process exited, code=killed, status=6/ABRT sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Unit entered failed state. sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Failed with result 'watchdog'. sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Service has no hold-off time, scheduling restart. sty 30 14:03:54 liori-pc systemd[1]: Stopped Flush Journal to Persistent Storage. sty 30 14:03:54 liori-pc systemd[1]: Stopping Flush Journal to Persistent Storage... sty 30 14:03:54 liori-pc systemd[1]: Stopped Journal Service. sty 30 14:03:54 liori-pc systemd[1]: Starting Journal Service... sty 30 14:03:54 liori-pc systemd-journald[23935]: Journal started sty 30 14:03:54 liori-pc systemd-journald[23935]: System journal (/var/log/journal/2318080f60e357aaf765e98d0000035c) is 2.1G, max 4.0G, 1.8G free.当使用 dm_crypt 时，一个
dmcrypt_write进程开始占用单个 CPU 内核的 100%（我后来从这个系统中删除了 dm_crypt，但仍然会发生停顿）。我观察
/proc/meminfo并看到这个Dirty数字永远不会超过几兆字节。值得注意的是，在停顿期间，这个数字不会改变。在极少数情况下，我什至会收到一条内核消息，格式为“INFO：task «some process»blocked for more than 120 seconds.”，«some_process»通常是 mdX_raid5、chromium 或其线程之一等。示例日志.
/dev/sdd最初，我的设置只是单个 1TB 驱动器（当前）分区上的单个 600GB ext4 文件系统。然后我迁移到 3×6TB 驱动器 ( /dev/sd{b,c,e})，使用基于 LVM 的 raid5、bcache 及其在 SSD 驱动器上的缓存，然后是 dm_crypt — 这就是停顿开始的时候。在调试的过程中，我将其简化为 LVM-raid5，没有 bcache 或 dm_crypt；摊位仍然会发生，尽管我觉得现在已经不那么频繁了。
这种失速一天会发生数次，通常持续几分钟。我注意到我可以通过明确请求一些磁盘操作来破坏它：我有时可以通过从远程机器上通过 ssh 登录到这个系统来破坏它，或者（几乎总是）通过cat /dev/sdb >/dev/null或者cat /dev/sdc >/dev/null（有时一个，有时另一个工作; 特别是cat /dev/sde >/dev/null从来没有帮助过）。然后，一切停滞不前的东西突然又开始工作了。
所以我怀疑问题是由以下之一或相互作用引起的：
- 驱动器：三个都是希捷 Skyhawk ST6000VX0023。其中两个在此设置之前未使用，第三个使用了半年（
/dev/sdc）。 - 磁盘控制器：主板：
Gigabyte Z68X-UD3H-B3有两个控制器：Marvell 88SE9172其中一个驱动器连接到其中，芯片组内置控制器（Intel® Z68）与另外两个（我可以检查哪一个在软件中的位置吗？）。 - 控制器内核驱动程序中的一些错误。
- LVM 或 raid5 中的一些错误。
这是一个 Debian Stretch 系统，安装了一些向后移植的软件包，最显着的是 kernel 4.19.0-0.bpo.1-amd64。英特尔酷睿 i7-2600k，16GB 内存。
在这一点上，我没有想法了。如何进一步调试此问题？
编辑：我开始了一个脚本，它每 4 秒从其中一个驱动器中读取一个随机扇区，并且现在 2 天没有停顿。因此，确实看起来某些系统组件（LVM？raid？）在必要时无法正确地将设备从某种低功耗模式中唤醒。
编辑：我不再可以访问这个系统，所以我不能再测试任何假设。我只能说，在运行该脚本后，我不再获得摊位。不过，我希望我知道如何调试它。