☰

当 `zpool` 命令挂起时无法进行 ZFS 管理

tag-icon • tag-icon terminal centos freeze sata centos-7
当 `zpool` 命令挂起时无法进行 ZFS 管理

我发现 zfs 在处理硬件故障方面表现不佳，甚至会完全挂起，除非系统重新启动，否则无法使用任何实用程序。zfs 是否被视为生产级？

我正在解决一些外部 SATA 驱动器与服务器计算机之间的连接故障，这些驱动器通过 USB3 或 eSATA 进行多路复用连接。这些问题仍然是个谜，但面对连接问题，zpool命令在任何运行它们的终端上都会永远阻塞。

在这个例子中，我简单地尝试了ls一个已安装的 zfs 池/池，但该终端挂起了。一个新终端 ( Alt+F2) 允许我尝试 zpool 状态，这也挂起了。Alt+F3我运行了另一个新终端 ( ) top，可以看到txg_syncCPU 使用率为 3%，以及无穷无尽的进程列表z_rd_int_x，每个进程的 CPU 使用率为 0.3%。第四个终端 ( Alt+F4) 是尝试zpool iostat，它也挂起了。

定期消息：

[tttt.ttttt] INFO: task bash:xxxx blocked for more than 120 seconds.
[tttt.ttttt] INFO: task txg_sync:xxxx blocked for more than 120 seconds.
[tttt.ttttt] INFO: task zpool:xxxx blocked for more than 120 seconds.

出现。该机器仍然通过 SAMBA 提供来自其他池的文件。

一个原本强大的大容量存储实现怎么会变得如此不堪一击？我如何才能优雅地解决这个问题而不只是重启？

  • 操作系统：CentOS 7
  • CPU：英特尔酷睿 i7 4770K 1150 RB 四核 3.5GHz
  • 内存：32GB 非 ECC
  • 驱动器：1TB WD Red WD10EFRX SATA 3.5 英寸

dmesg输出量很大，你可能需要告诉我你在寻找什么。

请根据需要询问更多信息。

答案1

答案不太好，但似乎设置failmode为continue所有池，任何池故障都将允许命令解释器继续运行。但这似乎存在危险，任何进一步的故障都可能造成更大的损害。

情况有点奇怪。为什么因为它管理的池挂起，命令解释器和整个终端也会挂起？管理工具和它们管理的东西之间难道不应该保持一定的距离吗？

相关内容