180天后是否要进行fsck

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

在小型文件系统上，此检查仅是一个不便。但是，对于较大的文件系统，此检查可能需要几个小时才能完成。当您的用户依靠此文件系统来提高工作效率时，例如说它正在通过NFS服务其主目录，您是否会禁用计划的文件系统检查？

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

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

作为标准维护的一部分，我通过使用完整的fsck进行预定的重启来解决fsck令人惊讶的多个小时停机问题。这比在生产期间遇到轻微的损坏并使之变成真正的停机要好。

问题的很大一部分是ext3的fsck异常缓慢。尽管xfs的fsck快得多，但是默认情况下，它在分配文件时使用了过多的内存，以鼓励在大型文件系统上使用xfs。但是，在大多数系统上这不是问题。切换到xfs至少会允许相当快的fsck。这可能使在常规维护中运行fsck的计划更加容易。

如果您正在运行RedHat并考虑使用xfs，则必须注意它们强烈不鼓励使用xfs，以及您在运行的内核上很少有人使用xfs的事实。

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

我要说的这是生产服务器不应该单独运行并且始终具有热/冷备份或参与两个节点群集的另一个原因。在当今的虚拟化时代，您可以轻松拥有一台物理主服务器和一台虚拟服务器，这只是每隔X天完成的物理副本的一部分，随时可以接管。

除了这个不是那么有用的答案之外，我想说的是您应该平衡数据的重要性...如果这仅仅是一个群集节点，请跳过它。如果这是客户端的非备份Web服务器，则可能需要在下一次进行计划：-)

视情况而定。例如，我们有一台服务器因运行QMail堆栈的例行维护而停机。随着时间的流逝，QMail创建并杀死了许多文件，这是一个非常繁忙的邮件服务器。fsck花了大约36个小时。并不是说我们从交易中节省了很多性能，但最终我想您可以认为文件系统更健康。尽管真的造成了混乱，这真的值得吗？不。在。所有。

XFS很有趣。它是始终一致的FS。它不需要fsck。不会因为fsck而导致停机。

但这还有另一个问题。您需要一个支持处理HDD坏块的RAID控制器。

当操作系统开始了解坏块并且HDD硬件坏块列表已满时，XFS没有将坏块列入黑名单的功能。

ext2 / 3/4，fat，ntfs等（脱机测试）能够将坏块列入黑名单，但不能将XFS列入黑名单。

因此，对于非企业安装，XFS可能不太适合。我正在将XFS​​与Linux软件raid1一起用于备份分区，该备份分区中的内容是许多小文件，并且随着时间的推移没有太大变化。