如何保持文件服务器的完整性而不用chkdsk离线？

微软已经发布了指导性的指导，以改善运行检查盘的性能和最小化停机时间：

NTFS Chkdsk最佳实践和性能
https://www.microsoft.com/downloads/en/details.aspx?FamilyID=35a658cb-5dc7-4c46-b54c-8f3089ac097a

特别要注意的是：

• 卷大小对性能没有影响。

• 对于拥有大量文件（数亿/十亿）的卷来说，为chkdsk利用更多内存的性能提升是巨大的。

• Windows 2008 R2 chkdsk是Windows 2008性能的两到五倍.Windows 2003非常糟糕，他们可能不好意思发布统计信息。

• 您应该在计划的重新启动之前主动检查卷是否脏。 这可以帮助减轻意外的多小时启动延迟的影响。

不是在文档中，但强烈build议：使用多用途服务器为文件服务数以亿计的文件增加了可能发生崩溃的可能性，并将卷标记为脏。 应采取措施确保不会发生事故。 一个例子是不使用文件服务器作为打印服务器（打印机驱动程序在蓝屏地区有一个臭名昭着的历史）。 另一个例子是“文件归档软件”。 强烈build议使用延长运行时间的备用电源。

在我看来，chkdsk不是执行预防性维护的工具。 如果你必须定期运行chkdsk来纠正问题，那么你就有一个潜在的问题需要解决。

我用大约7TB的一般用户数据来维护文件服务器。 7TB主要是由办公室types的文件构build的，所以我们正在谈论数百万。 我没有确切的数字，因为它需要这么长的时间才能得到，但在我们的Server 2008故障转移群集的各种文件系统中，有大约7-12百万个文件。

我们从来没有运行chkdsk，除了解决问题，我们从来没有整理碎片。

NTFS现在已经足够自我修复了，所以我们很less遇到问题。 当我们遇到问题时，通常是由于存储系统基础设施的故障造成的。 自发的光纤通道arrays控制器重新启动，FC交换机恐慌和重启，那种事情。 从服务器后面拔出电源显然是可以生存的。

事实上，我们最近幸免于一场灾难性的UPS故障。 整个房间同时下降。 NTFS恢复了一个窥视，并且不需要运行chkdsk。

关于碎片整理…我们的FC磁盘arrays中有48个驱动器，因为它是惠普EVA，条纹随机分布在主轴上。 这意味着就驱动器而言，即使很大程度上顺序访问实际上是随机的，这进一步意味着一个显着顺序的文件系统比一个显着分散的文件系统执行的最小程度更好。 因此，常规碎片整理很less帮助I / O开销。

至于预防性维护，NTFS现在已经足够自动化，几乎可以完成所有这些工作。 偶尔我会以只读模式运行chkdsk ，看看在全模式下运行它是否值得。 到目前为止，我们的集群还没有被需要 。 即使在我们的2TB上，它也能在不到一天的时间里运行4百万个文件LUN。

也就是说，有一些架构决策可以帮助减less离线chkdsk的最终需求，并且如果您需要做一个更快的操作，就可以更快地进行：

• 将RAID / SAN控制器上的高速caching策略设置为不caching写入。 但是，这就是为什么电池支持caching存在，所以性能打击这将不需要采取。 但是这是防止离线chkdsk最重要的事情。
• 保持较小的LUN。 文件数量比尺寸更重要。 一个满载Ghost映像的6TB LUN将比一个满载6KB文件的512GB LUN检查快得多。
• 保持足够的自由空间。 根据完全主观的标准，一个好的经验法则是在任何时候都有不less于15％的免费。
• 如果您的数据允许，请使用比NTFS的默认4KB块大的块大小。 在对我的文件做一些统计之后，我发现我的大部分文件系统都可以使用16KB的块。 较大的块意味着要检查的块越less，也使存储子系统能够更好地利用预读。 是的，小文件消耗更多的空间，但在我们的卷上它只增加了大约4％的总大小。

在之前的工作中，我们使用了Tripwire。 欲了解更多信息，你可以看看这里： Tripwire文件完整性pipe理器

在这里，您还可以find市场上文件完整性检查解决scheme的概述： 文件完整性检查器