在 Linux 中监控 XFS 文件系统运行状况

Question

我最近经历了文件系统崩溃。我有一台服务器不间断地运行了大约 180 天，没有任何问题，但后来我注意到发生了奇怪的事情，显然 ext3 文件系统处于非常糟糕的状态。我测试了驱动器和内存，它们都很好。最终，我被迫对系统进行软管冲洗并完全重新安装。fsck.ext3只会让事情变得更糟。

现在，我不希望这种情况再次发生，所以这次我改用了 XFS，我觉得它比 ext3 更成熟，但我不知道如何监控文件系统的健康状况。xfs_check根本不会让我在安装时扫描设备。

那么，您如何在系统在线时监控 XFS 文件系统的健康状况？

Answer 1

说实话，您无能为力来监控文件系统本身的运行状况。这个线程解释了为什么你不能对作为读/写在线的文件系统执行 fsck 样式检查的原因。

在某种程度上，您应该相信，作为日志文件系统，XFS 正在尽最大努力使您的数据保持良好的健康状态。您也可能会感到宽慰，因为它xfs_check比fsck.ext3ext3 的 180 天/x 挂载规则快得多，而且 XFS 没有规定定期检查的方式。

编辑评论：

虽然我明白你曾经被咬过，两次害羞。我可以向您保证，“完全崩溃”不是与 UNIX 文件系统相关的系统问题。根据我的经验，此类事件往往只会在硬件故障、用户错误（无意冒犯）或两者兼而有之的情况下发生。然而，如果没有关于您之前的 ext3 安装出了什么问题的一些非常具体的细节，这在技术层面上很难与您推理。

Answer 2

将文件系统放在LVM 逻辑卷上，从逻辑卷创建一个临时快照，然后 fsck 这个快照（同时逻辑卷仍然在线）。

也许 Theodore Ts'o 的用于 ext3的e2croncheck脚本会让您入门。

（正如 3dinfluence 提到的：ZFS 绝对是更好的解决方案......）

Answer 3

我注意到奇怪的事情发生了

那么问题不在于文件系统（或者至少它极不可能）。ext3 是最常用的 FS 之一，任何严重到足以导致灾难性损坏的错误都应该已经被发现并修复。

原因在于其他地方，可能是硬件本身（可能是 RAM）。

回答您的问题：您可以在线检查 XFS 文件系统，但前提是它以只读方式安装。

Answer 4

不建议检查当前安装的任何文件系统的一致性。