到目前为止，我已经看到一篇关于性能和可伸缩性的文章，主要关注添加新链接需要多长时间。 但是有没有关于文件数量，文件夹数量，总大小等方面的限制的信息？
现在，我有一个单一的文件服务器，数百万JPG（约45 TB），通过几个标准的文件共享在networking上共享。 我计划创build一个DFS名称空间，并将所有这些映像复制到另一台服务器以实现高可用性。 我会遇到与DFS有关的其他问题，否则我不会遇到简单的文件共享问题？ 有更多的build议方式来复制这些数以百万计的文件，并使它们在networking上可用吗？
编辑2：
所有文件通常写入磁盘一次，之后永远不会修改。 他们唯一被修改的时候是最终被删除，可能几年后。 所以一切都是静止的。
编辑：
我会自己试验一下，写一篇关于它的博客文章，但是我还没有第二台服务器的硬件。 我想在购买45 TB的硬盘空间之前收集信息…
目前，我们正在使用2008 R2 DFSR，复制文件为57 TB（160万），总卷容量超过90 TB，没有任何问题。
所以MStesting的限制在这方面有点幼稚，恕我直言，他们应该购买更多的磁盘空间，并做更多的testing。 如果您对初始同步没有时间要求，DFSR也可以这样做。 它特别不喜欢在多个主机上修改相同的文件，因为它必须执行仲裁。
使用45TB的数据，您可以达到Server 2008上DFS-R的testing限制：
DFS-R：常见问题
服务器上所有复制文件的大小：10兆兆字节。
卷上的复制文件数量：800万。
最大文件大小：64千兆字节。
编辑：
如果您的文件可能永远不会改变，您可以利用DFS的名称空间部分为您的共享创build虚拟path。 然后，您可以在计划任务中运行robocopy来同步您的服务器。 即使您打算使用DFS-R，也需要使用类似robocopy的东西来进行初始同步。
“还有一种更推荐的方式来复制这些数以百万计的文件，并使它们在networking上可用吗？” 是的 – 无论是SAN或NAS设备集中他们，或像Isilon，Gluster等分布式存储。DFS是好的，但这意味着每个服务器都有一个完整的副本，所以这不是一个好的架构，如果你需要规模更大。
而且，你的架构可能无法扩展。 我已经看到了一些不存储为文件的大型图像系统 – 它们有一个数据库，用于存储图像的元数据和字节偏移量，并将其汇集成大的二进制文件，这些二进制文件的分发方式非常简单磁盘和文件系统。 需要一个图像，它会查找blob文件，并从开始和结束字节拉出图像。