默认情况下，在180天或者一些挂载之后，大多数Linux文件系统强制进行文件系统检查（fsck）。 当然这可以closures，例如，在ext2或ext3上使用tune2fs -c 0 -i 0。
在小文件系统上，这个检查仅仅是一个不便之处。 但是，如果文件系统较大，则此检查可能需要几小时才能完成。 当你的用户依靠这个文件系统来提高他们的工作效率时，比方说他们通过NFS服务他们的主目录，你会禁用预定的文件系统检查吗？
我问这个问题，因为它是目前2:15，我正在等待很长的fsck来完成（ext3）！
180天的默认fsck时间是解决ext3不支持在线一致性检查的devise缺陷的一种解决方法。 真正的解决scheme是find一个支持这个的文件系统。 我不知道是否有成熟的文件系统。 这是一个真正的悲剧。 也许btrfs会拯救我们一天。
作为标准维护的一部分，我已经通过fsck做了定时重新启动，对fsck多小时的宕机问题做出了回应。 这比在生产时间内发生轻微的腐败要好，并且变成真正的中断。
问题的一大部分是ext3有一个不合理的缓慢fsck。 尽pipexfs的fsck速度更快，但它在分布上使用了太多的内存，以便在大型文件系统上默认鼓励xfs。 尽pipe如此，在大多数系统中这是一个没有问题的问题。 切换到xfs将至less允许一个相当快的fsck。 这可能会使运行fsck作为正常维护的一部分更容易安排。
如果你正在运行RedHat并考虑使用xfs，那么你必须小心他们不鼓励使用xfs，以及可能很less有人在运行的内核上使用xfs。
我的理解是，ext4项目的目标至less有点改善fsck性能。
我想说，这只是生产服务器不应该单独运行的另一个原因，并且总是要么进行热/冷备份，要么参与双节点集群。 在虚拟化的这些日子里，你可以很容易地拥有一个物理主服务器和一个虚拟服务器，这个服务器只是每隔X天完成的一个物理副本，随时可以接pipe。
其他那么这不是那么有用的答案，我会说，你应该平衡你的数据的重要性…如果这只是一个群集节点，跳过它。 如果这是一个客户的非备份的Web服务器，你可能想要下次提前计划:-)
取决于..例如，我们有一台服务器停机进行日常维护，运行一个QMail堆栈。 随着时间的推移，QMail会创build并杀死大量文件，而且这是一个非常繁忙的邮件服务器。 fsck花了大约36个小时。 这不像我们在交易中挽救了一大堆performance，但是最终我认为你可能会认为文件系统更健康。 是否真的值得接下来的混乱？ 不。 在。 所有。