180 天后转 fsck 或不转 fsck

Question

默认情况下，在 180 天或一定数量的挂载后，大多数 Linux 文件系统会强制执行文件系统检查 (fsck)。当然，这可以关闭，例如，在 ext2 或 ext3 上使用 tune2fs -c 0 -i 0。

在小型文件系统上，这种检查只是一种不便。但是，对于较大的文件系统，此检查可能需要数小时才能完成。当您的用户依赖此文件系统来提高工作效率时，假设它通过 NFS 为他们的主目录提供服务，您会禁用计划的文件系统检查吗？

我问这个问题是因为现在是凌晨 2 点 15 分，我正在等待很长时间的 fsck 完成（ext3）！

Answer 1

180 天的默认 fsck 时间是针对 ext3 不支持在线一致性检查的设计缺陷的一种解决方法。真正的解决方案是找到一个支持这一点的文件系统。我不知道是否有任何成熟的文件系统。这是一个真正的悲剧。也许有一天 btrfs 会拯救我们。

作为标准维护的一部分，我通过使用完整的 fsck 执行计划重新启动来解决 fsck 意外停机数小时的问题。这比在生产时间遇到轻微损坏并使其变成真正的中断要好。

问题的很大一部分是 ext3 的 fsck 太慢了。尽管 xfs 的 fsck 速度要快得多，但它在发行版中使用了过多的内存，以鼓励在大型文件系统上默认使用 xfs。尽管如此，在大多数系统上，这不是问题。切换到 xfs 至少会允许相当快的 fsck。这可能会使运行 fsck 作为正常维护的一部分更容易安排。

如果您正在运行 RedHat 并考虑使用 xfs，您必须注意他们对使用 xfs 的强烈反对，以及可能很少有人在您运行的内核上使用 xfs 的事实。

我的理解是 ext4 项目的目标是至少在一定程度上提高 fsck 的性能。