Is It Finally Time to Adopt Microsoft's Resilient File System?
Designed to replace NTFS, the Resilient File System--or, ReFS--helps guard against data corruption. So, why is it taking enterprises so long to embrace it?
October 3, 2019
![Is It Finally Time to Adopt Microsoft's Resilient File System? Is It Finally Time to Adopt Microsoft's Resilient File System?](https://eu-images.contentstack.com/v3/assets/blt8eb3cdfc1fce5194/blt24fa56fce3be4264/662119ea9a45aa48e17667ac/Open_20File_20Cabinet_20Drawers.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
When the ReFS file system was introduced in Windows Server 2012, it was designed to be a next-generation replacement for Microsoft’s aging NTFS file system. NTFS has existed since the mid-90s, and Microsoft wanted to bring its operating systems up to date with a more modern file system. Early on, the ReFS file system held great promise. Also known as the Resilient File System, ReFS originally included numerous features designed to help guard against data corruption. In spite of all these safeguards, however, relatively few organizatons actually adopted ReFS when it was initially made available. That may be changing.
Some people attribute the initial lack of adoption to the “if it isn’t broke, don’t fix it” philosophy. NTFS was, and remains, a very good file system. For many people, there probably wasn’t a compelling reason driving them to switch to a new and unfamiliar file system.
The low adoption rate might also have been attributed to a general distrust of the new file system. As previously noted, the NTFS file system has been around since the 90s. Because of its longevity, the NTFS file system has had plenty of time to mature. Even today, NTFS is widely regarded as a very stable and reliable file system. Conversely, the ReFS file system had not been around long enough to prove itself a worthy successor to NTFS.
Perhaps the biggest reason why the ReFS file system initially saw such limited adoption, however, was because it had some rather significant limitations. Even though ReFS was based on the NTFS file system, there were a number of NTFS features that it did not support. For instance, ReFS did not support EFS encryption, nor did it support Windows Servers’ native deduplication feature. When you also consider that ReFS was not supported for use on a boot drive, and that there was no direct upgrade path from NTFS, it is little wonder why so few people chose to use the ReFS file system.
It is worth remembering, however, that the ReFS file system was released way back in 2012. In the years since its release, ReFS has had some time to mature. Not only has the file system been proven to be stable, it has been enhanced over the years and is now far less limiting than it once was. For example, Microsoft added data deduplication support to ReFS in Windows Server version 1709. Similarly, Microsoft began supporting ReFS for use on a cluster shared volume in Windows Server 2012 R2.
This isn’t to say that ReFS now supports the same feature set as NTFS. ReFS still has some significant limitations that you need to be aware of if you are thinking about making the switch. Specifically, you can’t use ReFS on a boot drive, and you cannot place the Windows pagefile onto a volume that is formatted with the ReFS file system. Similarly, ReFS does not support file system level compression or encryption or storage quotas. ReFS also won’t work on removable media, and it doesn’t support the old 8.3-style short filenames.
On the other hand, ReFS does have several things going for it. As previously mentioned, ReFS was specifically designed to help maintain data integrity. And, unlike NTFS, ReFS supports block clone, sparse VDL and mirror accelerated parity.
ReFS is also far more scalable than NTFS. The NTFS file system has a maximum volume size and maximum file size of 256 TB. At one time 256 TB seemed like an astronomical amount of storage capacity. Today though, 256 TB storage volumes are relatively common.
ReFS directly addresses the NTFS file system’s capacity limitations by increasing the maximum volume size and the maximum file size to 35 PB.
So, with these issues in mind, one has to consider whether it might be time to consider adopting the ReFS file system. With that said, there are some significant benefits to using the ReFS file system, there are just as many reasons not to use it. As such, it is best to choose a file system based on how a volume will be used.
ReFS probably isn’t the best choice for file server volumes, for example, because of the fact that the file system lacks support for storage quotas and short file names. If, on the other hand, you need to host a massive SQL Server database, then ReFS is an excellent choice because of its scalability and its efforts at maintaining data integrity.
About the Author
You May Also Like