我正在处理几台 Linux VM，它们的分区安装在 NetApp NAS 上。此 NAS 定期出现非常高的 iowait 问题，这会导致 VM 磁盘切换到只读模式、崩溃或损坏。
在VMware 知识库建议增加超时值作为姑息治疗方法：
echo 180 > /sys/block/sda/device/timeout
设置非常高的超时时间（1800 或更高）可能有什么负面影响？在我看来，风险在于延迟的写入会累积并填满 I/O 写入缓冲区，从而导致系统崩溃。因此，此解决方案可能比问题更糟糕。
答案1
大多数写入操作都被缓存在操作系统脏页缓存中，已经异步完成。换句话说，它们通常与设备超时无关。
但是，读取和同步写入需要底层块设备的立即关注，这正是文件系统切换到只读模式（它无法将其日志写入磁盘）的原因。
增加 I/O 等待时间应该不会产生不良影响，但这不是灵丹妙药。例如，即使底层文件系统仍处于读写模式，数据库也可以进入只读模式。
答案2
请注意，默认的 SCSI 超时时间已经是 30 秒。从计算机的角度来看，这已经是一段相当长的时间了 :-P。
IO 请求（例如异步写入）受/sys/class/block/$DEV/nr_requests、 和 的限制/sys/class/block/$DEV/max_sectors_kb。在旧的单队列块层中，总内存使用量被称为2*nr_requests*max_sectors_kb。因子 2 是因为读取和写入是分开计算的。尽管您还需要考虑硬件队列中的请求，例如参见cat /sys/class/block/sda/device/queue_depth。通常，您需要确保最大硬件队列深度不大于 的一半nr_requests。
1）有文字记载如果您的 IO 请求需要太多空间，您将会出现内存不足错误。 因此，您可以在特定系统上查看上述值。通常它们不是问题。 nr_requests默认为 128。默认值max_sectors_kb取决于您的内核版本。
如果您使用新的多队列块层 (blk-mq)，则读取和写入不会单独计算。因此，等式中的“乘以 2”部分消失了，而是nr-requests默认为 256。我不确定硬件队列（或多个队列）在 中是如何处理的blk-mq。
当请求队列已满时，异步写入会在页面缓存中累积，直到达到“脏限制”。历史上，默认脏限制被描述为 RAM 的 20%，尽管如今确切的确定略微复杂一些。
当达到肮脏极限时，你只需等待。 除了 SCSI 超时之外，内核没有其他硬超时。 从这个意义上讲，有关此主题的常见文档（包括 VMware KB）已经足够了。不过，您应该搜索适用于您的 NAS 的特定文档 :-P。不同年份的 NAS 经过精心设计，可提供不同的最坏情况时序。
2) 也就是说，如果某个进程等待磁盘 IO 的时间超过 120 秒，内核将打印“挂起任务”警告。（可能。这是通常的默认设置。除了我的 Fedora Linux 版本，内核似乎是在没有 CONFIG_DETECT_HUNG_TEST 的情况下构建的。Fedora 似乎在这里是一个奇怪的异常值）。
挂起任务消息不是崩溃，并且它没有设置内核“受污染”标志。
在 10 个挂起任务警告（或您设置的任何警告sys.kernel.hung_task_warnings）之后，内核将停止打印它们。考虑到这一点，我认为您还应该增加，sysctl sys.kernel.hung_task_timeout_secs使其高于您的 SCSI 超时，例如 480 秒。
3) 各个应用程序可能有自己的超时。您可能更愿意看到应用程序超时，而不是让内核返回 IO 错误！文件系统 IO 错误通常被认为是致命的。根据配置，文件系统本身可能会在 IO 错误后重新挂载为只读。交换设备或内存映射文件中的 IO 错误将向受影响的进程发送 SIGBUS 信号，这通常会终止该进程。
4) 如果使用systemd，则配置了看门狗定时器的服务可能会被强制重启。在 的当前版本中systemd，如果您运行 ，则可以看到例如 3 分钟的超时systemctl show -p WatchdogUSec systemd-udevd。四年前增加了这个限制出于不同的原因；这似乎只是巧合，这与 VMware 建议的 SCSI 超时时间相符 :-)。这些重新启动可能会产生令人担忧的日志噪音。 systemd使用 SIGABRT 终止进程，目的是获取核心转储以显示进程卡住的位置。然而，现在像 udev 甚至 journald 这样的东西应该很乐意重新启动。
主要关注的是确保您没有配置太短的用户空间重启看门狗，RuntimeWatchdogSec=例如/etc/systemd-system.conf。 即使您不使用交换，也有可能被systemd进入内核“直接回收”的内存分配所阻塞。