Windows Server 2012 – File System Resiliency (ReFS) or Data Deduplication (NTFS)?

Windows Server 2012 – File System Resiliency (ReFS) or Data Deduplication (NTFS)?

One of the features of Windows Server 2012 R2 that I’ve been doing research as of late is the new file system Resilient File System ReFS). The big question as you can imagine is whether to use it or not. What became clear from the get go was that ReFS offers a subset of the features available to NTFS, some which are critical for certain business/users. So what does ReFS really has going for it if it is not a fully featured File System? you ask. Well, in one word resiliency. It is meant to offer otherworldly resiliency when compared to NTFS in return of all those cool features we all love.

One of the big ones for me is Data Deduplication. Because of the tons of backups out there and VMs Data Deduplication has actually achieved over 50% in disk space savings so giving up on Data Deduplication is a big thing. Fortunately space is not really an issue at this point, but for some people that might just break the deal. On the other hand I was reading ReFS is the way to store data, specially files that don’t change often (say Vhdx files) and backups. Why backups I wonder as they are prime candidates for data deduplication but here comes the risks: When using data deduplication your life (I mean the integrity of your data) hinges on your data chunks. What happens say one of them gets corrupted, then if 50 or so files were using that chunk as means of deduplication then you´ve just corrupted 50 or so files. I am suspecting that is the reason why Microsoft is not supporting data deduplication on ReFS volumes. Resiliency and Data deduplication seem to not get along from a philosophical point if you want. So really what you could say is that I have learned that each file system at this point in time has a very particular need that it fills so potentially you are stuck with 2 drives each with a different file format for the time being. ReFS being the ideal file system while NTFS being the full featured file system for everything else.

So at this point what I want to do is bring together a summary of all the information that might help with deciding when to use each file system and then provide a reference to all those articles where this information was obtained. That way if you just want a quick overview you can focus in the summary while you can dig in if you want to fully grasp the concepts.

Why choose ReFS over NTFS?

• Integrity offered by automatic correction of data corruption.
• Designed to stay ONLINE as long as possible – if data corruption occurs, only that sector is ‘corrected’ or taken offline. Typically with NTFS volumes, corruption means running a CHKDSK which can take many hours to days even.
• Salvage – “a feature that removes the corrupt data from the namespace on a live volume”. What this means is that even if there is corruption on the volume which cannot be repaired, the file system will savage those sectors so that the volume still remains online.
• ReFS works with Storage Spaces to Better Detect and Repair Problems. The one particular feature that stands out is that if you have a mirrored storage pool if one of the drives becomes corrupted ReFS would find that information on another disk and restore the information automatically. During the entire process you do not suffer any downtime.
• ReFS is Much Better at Handling Power Outages: Instead of writing over the existing metadata when you perform a change, it writes it on an empty space and once the operation is completed the change takes place preventing a sudden loss of power to result in half-written metadata which can happen in NTFS.
• ReFS Supports Long File Names and File Path. The limitation on full path size has also been updated from 255 characters for the total path size to 32K (32,768).

Why choose NTFS over ReFS?

• Been around for almost 20 years (July 2013 will be its 20th anniversary).
• If you need or use any one of the following as they are no longer available on the ReFS: named streams, object IDs, short names, compression, file level encryption (EFS), user data transactions, sparse, hard-links, extended attributes, and quotas.
• Data deduplication.
• Replication using DFS.
• Some programs might use file locks or other features that might prevent proper functioning on ReFS. I already had to move folders back to NTFS because of that. I’ve read SQL databases don’t work well with ReFS as well as Virtual Machines. So you probably want NTFS to run those two among other applications.

When you install the Data Deduplication role service on a server running Windows Server 2012, DDPEVAL.EXE is also installed in the C:WindowsSystem32 folder as an additional command-line tool.  DDPEVAL.EXE can be run against any local NTFS volumes or NTFS network shares to estimate the amount of disk space that can potentially be reclaimed by moving that data to a Windows Server 2012 NTFS volume with Data Deduplication enabled.

C:> DDPEVAL \serverfolder /V /O:logfile.txt

Comparing ReFS and NTFS Features

Although ReFS is a different file system, there are similar features between ReFS and NTFS. The easiest way to compare those is to look at the feature list side by side. Consider the following feature sets:

Additional reading

• Technet blog about ReFS here: http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx
• http://emtunc.org/blog/06/2013/windows-server-2012-file-system-resiliency-or-data-deduplication/
• http://www.petri.co.il/4-reasons-refs-is-better-than-ntfs.htm#
• http://en.wikipedia.org/wiki/ReFS
• http://blogs.technet.com/b/askpfeplat/archive/2013/01/02/windows-server-2012-does-refs-replace-ntfs-when-should-i-use-it.aspx
• http://www.firstever.eu/en/refs-vs-ntfs-benchmark/: A bunch of benchmarks. Basically it seems they perform about the same with ReFS taking a small lead on most of the tests.