我最近经历了文件系统崩溃。我的服务器连续运行了大约 180 天，没有任何问题，但后来我注意到发生了奇怪的事情，显然 ext3 文件系统状况非常糟糕。我测试了驱动器和内存，它们都很好。最终，我被迫关闭系统并进行完全重新安装。fsck.ext3只会让事情变得更糟。
现在，我不想再发生这种情况，所以这次我选择了 XFS，我觉得它比 ext3 更成熟，但我不知道如何监控文件系统的健康状况。xfs_check根本不让我在安装设备时扫描它。
那么，如何在系统在线时监控 XFS 文件系统的运行状况？
答案1
说实话，你无法做太多的事情来监控文件系统本身的运行状况。此主题解释了为什么无法对以读/写方式在线的文件系统执行 fsck 样式检查的原因。
在某种程度上，您应该相信，作为日志文件系统，XFS 会尽最大努力保持数据健康。您还可以稍感安慰的是，它比 ext3 的 180 天/x 挂载规则xfs_check快得多fsck.ext3，并且 XFS 不会规定定期检查。
编辑评论：
虽然我知道你一朝被蛇咬，十年怕井绳。但我可以向你保证，“彻底崩溃”不是与 UNIX 文件系统相关的系统性问题。根据我的经验，此类事件往往只会在硬件故障、用户错误（无意冒犯）或不幸的两者混合时发生。然而，如果没有关于你之前安装的 ext3 出了什么问题的非常具体的细节，很难从技术层面上与你讲道理。
答案2
将文件系统放在LVM 逻辑卷，创建一个临时快照从逻辑卷，然后 fsck 此快照（当逻辑卷仍然在线时）。
也许是 Theodore Ts'o 的e2croncheckext3 脚本将帮助您入门。
（正如 3dinfluence 提到的：ZFS 绝对是更好的解决方案......）
答案3
我注意到奇怪的事情发生了
那么问题就不是文件系统（或者至少极不可能）。ext3 是最常用的文件系统之一，任何严重到足以导致灾难性损坏的错误都应该已经被发现和修复。
原因在于其他方面，可能是硬件本身（可能是 RAM）。
回答您的问题：您可以在线检查 XFS 文件系统，但前提是它以只读方式安装。
答案4
简短免责声明：我喜欢 XFS 及其速度。 这与其说是咆哮，不如说是警告。
立即回答：不，您需要卸载文件系统才能执行检查。在实时文件系统上运行 fsck 是一件坏事。文件系统在这样的检查下不断变化，这意味着您永远无法真正确定它是否在不断被检查，或者更糟的是，您的“修复”是否会使情况变得更糟。
虽然这不是直接的答案是明确的。 Ext3 可能对你来说是更好的选择，如果您遇到 Ext3 损坏，那么您需要重新检查硬件。出于对 ${DIETY} 的热爱，如果您正在寻找在恢复期间不会（潜在地）丢失数据的东西，那么您不应该使用 XFS。 在某些情况下它将恢复期间将数据块清零。
引用自第二个链接：
5.1 写入失败
数据：我们发现数据错误大多被忽略，或者除了通知用户错误之外很少采取任何措施。在大多数情况下，数据丢失是悄无声息地发生的，用户对此毫不知情。
请记住，XFS 最初设计时就考虑到了视频工作，因此如果您的视频文件损坏了，也没什么大不了的，您可以随时拼接视频来修补“坏点”；而等待几天对 14 TB 文件系统进行 fsck 却是一件大事，因此它用检查时间换取数据完整性。