我想这是一个古老的问题，但我在网上find的所有答案都是非常分散的，所以这里…
我需要为成千上万个〜10MiB和〜50MiB文件的专用卷。 我怀疑一个大的NTFS簇大小会加快文件服务器的速度，但是大的簇大小是否会造成其他的负面影响，比如速度慢下来，还是浪费了大量的空间？
我应该使用64K群集，32K还是只是默认的（4K大小）？
据我所知，NTFS本身没有任何性能问题与更大的簇大小相关联。
如果你真的想把所有的速度赶出去，我build议你进行模拟和基准testing。 如何应用程序读取数据（4K块，8K块等）将有所作为，就像NT高速caching上的高速caching命中模式和底层RAID高速caching一样。 磁盘/存储硬件（RAID布局，SANconfiguration等）也将有所作为。
最终，应用程序的行为将是性能最大的独裁者。 你可以在网上看到各种应用（Exchange，SQL Server等）的“规划指南”。 所有严重的问题都是基于真实世界的负载模拟基准。 你可以写出“经验法则”，但是对于任何给定的系统来说，在较低的层次上可能会有怪癖，这些都会在他们的耳朵上产生经验。
如果您的应用程序适合于模拟工作，则使用各种文件系统/ RAID /磁盘configuration，启动一个模拟的文件语料库并模拟其中的工作负载。 这将是唯一可以肯定的方法。
（旁白：其他人觉得有趣的是听到一个叫做“小”的10MB文件吗？上帝，我老了…）
简单的回答：如果你的大部分文件都是10MB或者更多，那么我build议你尽可能使用更大的簇大小，但这在空间上可能有点浪费。
复杂的答案：你应该分析你的磁盘caching，你的磁盘控制器的caching，你的操作系统的caching和实际的文件和它们的大小。 这会更好，但更难得到正确的。