我们有一个应用程序计划存储大约1.1TB的XML文件，平均大小为8.5kb。
这些代表了18个月的滚动数据，每天创build大约20万个新文件。
每个文件只会被写入一次，然后在接下来的18个月内有3％的几率被读取一小部分（<10）次。
目前在我们名单上的是：
关于碎片：我们计划使用2k簇大小来提高磁盘空间的使用效率。 每个文件将只写一次（即没有文件编辑）。 文件将在18个月后每天被删除。
因此，我们不相信分裂将是一个重大问题。
我还要补充：
closures磁盘碎片整理。 将块大小更改为16kb，以便将每个文件写入一个块。
理性为此：
你想要每天写入1.7GB的数据，在20万个文件中。 假设这些文件在24小时内写入，这意味着每秒大约3个文件。 这似乎不是一个单一的SATA磁盘的重大问题，所以我的猜测是，你有其他问题，以及磁盘性能。
（即，你有足够的内存吗？或者你是否将内存分页到磁盘？）
然而
Windows NTFS文件系统默认尝试在后台对文件系统进行碎片整理。 在对磁盘进行碎片整理时，磁盘碎片整理会导致性能下降。 由于表演似乎已经成为一个问题，这只会让事情变得更糟。
在编写大文件时，使用小簇大小和IO性能之间是平衡的。 文件和文件分配表不会在磁盘上的同一个扇区上，因此在写文件时不得不分配块，这将导致磁盘头不断移动。 使用能够将文件的95％存储在一个群集中的群集大小可以提高IO写入性能。
正如其他人所指出的那样，使用2k的微小簇大小会随着时间的推移而导致碎片化。 想想这样，在前18个月，你将文件写入干净的空磁盘，但操作系统不知道，一旦closures，没有更多的数据将被添加到每个文件，所以它已经留下了一些块在结束每个文件之后该文件被延迟。 在填充磁盘之前很久，您会发现唯一的空闲空间在其他文件之间的空隙中。 不仅如此，当它为您的文件select一个空白时，操作系统不知道您是在编写一个5个块文件还是一个2个块文件，因此无法在保存文件的位置上做出正确的select。
最后，工程就是要处理相互冲突的需求，并select成本最低的解决scheme来满足这些平衡需求。 我的猜测是，购买更大的硬盘可能比购买更快的硬盘便宜。
禁用上次访问时间戳并为MFT保留空间。
详细说明我对托勒密的回答的评论…
通过设置块大小，使得每个文件的绝大部分都包含在一个块中，您可以获得I / O效率。 对于2K的块大小和8.5K的平均文件大小，50％的I / O操作将会达到5块或更多。 通过设置一个16K的块大小，这听起来像是绝大多数的写入将是一个块; 这会使那些读取的3％的读取效率更高。
有一点要考虑的是备份I / O。 如果您要备份数据，每个文件至less读取一次，并且每个备份过程都将控制其目录条目。 如果您打算将其备份，请考虑您的devise中的备份I / O。
注意事项：如果您的底层存储系统已经做了一些存储虚拟化（例如HP EVA磁盘arrays或该类别的其他arrays），那么这并不重要。 这种types的碎片不会被注意到，因为数据已经在实际的驱动器上高度分散的存在。 在这种情况下，2k块大小就好，不会影响性能。 select足够大的块来保存大部分预期的文件大小仍然会有性能提升，但幅度不会太大。
这次派对迟到了，但是可能会让别人受益，所以…
回覆。 簇大小，首先也是最重要的，你需要看看文件大小的分布，所以你可以优化既低碎片又浪费磁盘空间，所以你要调整群集接近这个大小，而不是整体avg – 例如：如果大多数文件接近2k，则2k簇大小将是最优的，如果接近4k，那么4k簇将是最优的，等等。 如果文件大小是均匀/随机分布的，那么你可以做的最好的做法是接近平均文件大小的簇大小，或存储在不同的文件大小不同的簇大小的分区，像一些较大的系统一样， d需要软件/ fs的支持。
你可能也想看看你的deviseRAID。 有各种forms的RAID，但是你最好查看一下RAID 5，它可以让你同时把文件写入不同的驱动器，但是数据仍然在一个卷上…这给你几个好处：
1）您正在创build备份。 这可以让你有一个驱动器崩溃，你可以恢复。 RAID 1将创build一个镜像副本，但5涉及条带 – RAID 1只会给你的备份的好处…虽然5会涉及更多，你需要更多的驱动器来设置它（至less3，与RAID 1需要2个），你还有其他的好处。
2）条纹也提高了性能，因为你可以一次写入多个文件（估计每秒3次，上面…），条纹将允许文件沿着磁盘“分布”，并且每个磁盘只占用一部分的负担。 涉及的磁盘越多，每个磁盘的负担就越轻，但是会有一个地方可以达到性能与成本的极限。
3）如果备份数据，备份可以在不降低任何写入性能的情况下进行 – 取决于磁盘caching的大小，当然还有备份的forms……但是大部分情况下，不需要closures以调用备份。
另外，您设置系统的方式，甚至听起来就像备份会更容易 – 您只需要一次备份24小时的数据，因为以后不会修改该文件。 如果您担心文件占用的空间，您甚至可以编写压缩数据的批处理作业… XML主要是文本，因此压缩率会很高，很less需要解压缩，仅占3％的文件…所以你可以包括在驱动器上的压缩，而不用担心解压时间。 这也将减less所需的块大小，并且可以进一步提高系统的效率，CPU参与压缩数据，而不仅仅是数据的中介。 （IE）如果你所做的只是存储数据，那么这个系统中的CPU处理器会浪费掉，但是如果它使用“浪费的”时钟周期，压缩数据并更有效地分配给驱动器，更好！）
压缩，你的2K块可能会保持你的8.5K文件没有问题。 添加条带化和RAID备份，以及一个巨大的CPU，足够的内存不会caching任何正在运行的程序（如果有任何caching被使用的话），而且你正在为你正在寻找的好的系统做好准备。