So far I have seen an article on performance and scalability mainly focusing on how long it takes to add new links. But is there any information about limitations regarding number of files, number of folders, total size, etc?

Right now I have a single file server with millions of JPGs (approx 45 TB worth) that are shared on the network through several standard file shares. I plan to create a DFS namespace and replicate all these images to another server for high availability purposes. Will I encounter extra problems with DFS that I'm otherwise not experiencing with plain-jane file shares? Is there a more recommended way to replicate these millions of files and make them available on the network?


All files are usually written to disk once and never modified after that. The only time they are modified is when they are eventually deleted, possibly years later. So everything is pretty static.


I would experiment on my own and write a blog post about it, but I don't have the hardware for the second server yet. I'd like to collect information before buying 45 TB of hard drive space...

  • Talk about how frequently files are being modified, added, or deleted. Do you have directory hierarchies that will stay mostly unmodified after their initial replication? Commented Oct 18, 2012 at 22:39

3 Answers 3


We are currently using 2008 R2 DFSR with 57 TB of replicated files ( 1.6 Million ) and have an overall volume size in excess of 90 TB, without any issues .
So MS tested limits are a bit naive in this respect, and IMHO they should buy some more disk space and do some more testing. If you're not time critical on the initial sync DFSR can do that too. What it doesn't like especially is the same file being modified on multiple hosts as it has to do the arbitration on which to keep.

  • 2
    45 TB is what Microsoft tested at the time of the last update. This limit is a bit conservative, and is gradually increased over time. In 2010, it was 10 TB. This limit is primarily intended to prevent people from shooting themselves in the foot by putting all their data in a DFS-R basket until a giant crater forms.
    – Greg Askew
    Commented Nov 23, 2012 at 16:07
  • +1 Can't argue much with a real-world scenario similar to my own.
    – Phil
    Commented Nov 24, 2012 at 22:26

With 45TB of data, you are above the tested limitations of DFS-R on Server 2008, as per:


Size of all replicated files on a server: 10 terabytes.

Number of replicated files on a volume: 8 million.

Maximum file size: 64 gigabytes.


If your files will likely never change, you could utilize the namespace portion of DFS to create a virtualized path for your share. You could then run robocopy in a scheduled task to sync your servers. You would need to use something like robocopy for your initial sync, even if you were going to use DFS-R.

  • 1
    Correct me if I'm wrong, but I thought DFS-R did the initial sync for you.
    – Phil
    Commented Oct 19, 2012 at 13:44
  • 1
    Yes it can, but best practice is to pre-stage the data on the other server first. If you don't, DFS won't be fully functional until the initial sync is complete. It's faster to use something like robocopy, esp when dealing with larger amounts of data.
    – HostBits
    Commented Oct 19, 2012 at 14:00
  • @Phil When seeding massive amounts of data for DFS-R, it's a good idea to use robocopy to pre-seed the data. In this case, you might be best connecting the two servers directly and creating temporary static routes between them so that the seeding can happen over a dedicated link, since it will take a substantial amount of time to seed.
    – MDMarra
    Commented Oct 19, 2012 at 14:23

"Is there a more recommended way to replicate these millions of files and make them available on the network?" Yup - either a SAN or NAS device to centralize them, or distributed storage like Isilon, Gluster, etc. DFS is nice, but it means that every server has a complete copy of everything, so that's not a good architecture if you need to scale a lot bigger.

Also, your architecture might have difficulty scaling anyway. I've seen some large image systems that don't store as files - they have a database that stores the metadata and the byte offsets of the images, and rolls them up into big binary files that are distributed in a way that's easy on the disk and filesystem. Need an image, and it will look up the blob file and pull the image out of it with the start and ending byte.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .