默认情况下，在 180 天或一定次数的挂载后，大多数 Linux 文件系统都会强制执行文件系统检查 (fsck)。当然，可以使用例如 ext2 或 ext3 上的 tune2fs -c 0 -i 0 关闭此功能。
在小型文件系统上，此检查只是一种不便。但是，对于较大的文件系统，此检查可能需要数小时才能完成。当您的用户依靠此文件系统来提高工作效率时，假设它通过 NFS 为他们的主目录提供服务，您会禁用计划的文件系统检查吗？
我问这个问题是因为现在是凌晨 2:15，我正在等待一个非常长的 fsck 完成（ext3）！
答案1
180 天的默认 fsck 时间是针对 ext3 不支持在线一致性检查这一设计缺陷的一种解决方法。真正的解决方案是找到一个支持此功能的文件系统。我不知道是否有任何成熟的文件系统支持此功能。这真是一场悲剧。也许有一天 btrfs 会拯救我们。
我已经通过按计划重新启动并执行完整的 fsck 作为标准维护的一部分来应对 fsck 导致的意外数小时停机问题。这比在生产时间内遇到轻微损坏并导致真正停机要好。
问题很大一部分在于 ext3 的 fsck 速度太慢。虽然 xfs 的 fsck 速度快得多，但它占用了太多内存，因此发行版不鼓励在大型文件系统上默认使用 xfs。不过，在大多数系统上这不是问题。切换到 xfs 至少可以实现相当快的 fsck。这可能会使将 fsck 作为正常维护的一部分更容易安排。
如果您正在运行 RedHat 并考虑使用 xfs，那么您必须注意他们强烈反对使用 xfs，并且可能很少有人在您正在运行的内核上使用 xfs。
我的理解是，ext4 项目的目标是至少在一定程度上提高 fsck 的性能。
答案2
我想说，这只是生产服务器不应该单独运行而应该始终拥有热/冷备份或参与双节点集群的另一个原因。在虚拟化时代，您可以轻松拥有一个物理主服务器和一个虚拟服务器，后者只是每隔 X 天完成的物理副本，随时可以接管。
除了这个不太有帮助的答案之外，我想说你应该平衡数据的重要性...如果这只是一个集群节点，请跳过它。如果这是客户端的非备份 Web 服务器，你可能需要下次提前计划 :-)
答案3
视情况而定。例如，我们有一台运行 QMail 堆栈的服务器因例行维护而停机。随着时间的推移，QMail 会创建和删除大量文件，而这台邮件服务器非常繁忙。fsck 大约需要 36 个小时。这并不是说我们从这笔交易中节省了大量性能，但最终我想你可以说文件系统更健康。但这真的值得随之而来的混乱吗？不值得。一点也不。
答案4
XFS 很有趣。它是一个始终一致的 FS。它不需要 fsck。它不会因 fsck 而导致停机。
但是它还有另外一个问题，你需要一个支持处理硬盘坏块的 RAID 控制器。
当操作系统开始了解坏块并且 HDD 硬件坏块列表已满时，XFS 没有将坏块列入黑名单的功能。
ext2/3/4、fat、ntfs 等（离线测试）能够将坏块列入黑名单，但 XFS 不能。
因此，对于非企业安装，XFS 可能不太合适。我使用 XFS 和 Linux 软件 raid1 来备份分区，其中的内容是大量小文件，随着时间的推移不会发生太大变化。