一个无头 Linux NFS 文件服务器最近几天运行缓慢（基于用户的主观报告）。我检查了 journalctl，没有看到任何相关错误。
然而，当我连接显示器时，我看到的屏幕上全是这些错误：
failed command: WRITE FPDMA QUEUED
这是一张照片：
建议采取哪些后续措施？我应该更换磁盘吗？
答案1
根据此处显示的信息，只有一个磁盘有问题。但不清楚是驱动器、电缆还是控制器出了问题。
我会先重启，重置硬件。这可能只是控制器暂时混乱了，直接关闭再打开应该会有帮助。
如果重启后错误再次出现，那么我会将该驱动器插入另一个 SATA 端口，并在必要时将其他驱动器插入该端口。如果错误仍然出现在同一个端口上，那么问题就出在控制器上。
但如果错误“移动”到新端口，那么问题就出在电缆或驱动器上。此时，我会更换 SATA 电缆。如果错误消失，那么就是电缆坏了。如果仍然有错误，那么就是驱动器的问题。
答案2
您可以尝试的另一件事（远程工作）是运行smartctl -a以查看驱动器是否报告任何错误，并可能smartctl -t short对其进行自我检测。
就我而言，结果显示WRITE FPDMA QUEUED故障是由于ICRC（接口 CRC）错误引起的，这意味着驱动器和控制器之间的数据已损坏，因此磁盘本身没有问题，而且问题出在 SATA 电缆或 SATA 电缆插入的两端的电路上。
虽然我不是专家，但据推测在这种情况下该命令被重试并最终通过 SATA 电缆成功传输，并且没有被损坏，导致系统正常运行，但由于所有重试导致磁盘运行速度非常慢。
答案3
failed command: WRITE FPDMA QUEUED我在装有较旧款 i7 笔记本电脑（即英特尔芯片组）的 Apacer AS350 1TB 硬盘上遇到了同样的问题（ ）。
我在内核错误讨论中发现了这一点：
https://bugzilla.kernel.org/show_bug.cgi?id=203475#c15
我认为，如果您看到“WRITE FPDMA QUEUED”消息，则问题通常出在 NCQ 上，是的，您应该尝试为设备禁用它。但是，如果您看到“SEND FPDMA QUEUED”消息（如初始帖子中所示），那么您可能只需禁用排队的 TRIM 即可。
添加libata.force=1:3.0G,1:noncq“解决”了我的问题，但当然会减慢驱动器的速度。我认为这1:3.0G部分并不重要。
SSD 上的固件更新可能会解决此类问题，但 Apacer 仅提供基于 Windows 的固件更新，我无法轻松应用和测试。