Using the Resilient File System (ReFS) in Windows Server 2012
Should I use the Resilient File System (ReFS) in Windows Server 2012?
Microsoft introduced the first significant change to the file system in many years in Windows Server 2012. Resilient File System (ReFS) is built atop NTFS and improves upon the reliability and feature set already found in earlier versions of Windows Server. In its current incarnation, ReFS is limited to some specific uses. You should weigh up the pros and cons of the new file system before proceeding to format new volumes.
What Are the Main Benefits of ReFS?
Although NTFS is a reliable and mature file system, it can still be prone to file corruption and volume failure. ReFS is better at protecting data in the event of a power outage, can use checksums to verify the integrity of file data and metadata, and has better support for large volumes as corrupted files can be scrubbed or salvaged without taking disks offline. My favorite feature is support for long file names – up to 32,768 characters. For more information on these features, check out another Petri article, “4 Reasons ReFS (Resilient File System) is Better Than NTFS.”
Backwards compatibility was an important part of the development of ReFS, and while support for some NTFS features has been dropped, ReFS supports the most important NTFS functionality used today, including:
- BitLocker encryption
- Access-control lists (ACLs)
- USN journal
- Change notifications
- Symbolic links
- Junction points
- Mount points
- Reparse points
- Volume snapshots
- File IDs
As a Version 1.0 Feature, Is ReFS Ready for Production Use?
While we can safely assume that ReFS would not have been included in Windows Server 2012 had not been deemed ready for production environments, Microsoft states that as a version 1.0 file system, it is best to carry out tests in a lab environment before deploying ReFS on production servers.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Microsoft has carried out extensive testing of ReFS in-house, and as is standard practice with new file systems, is deployed only in Server, not Windows 8. Also, it cannot currently be used on boot volumes. The roadmap for ReFS is to introduce full ReFS support in Windows client OSes, and finally boot volume capability.
Microsoft states that ReFS is largely intended for use on file servers in conjunction with Storage Spaces. While there are other potential uses for ReFS, the ability to transparently repair corrupt data from good copies of files on Storage Space disk arrays was one of the primary reasons for its original conception.
ReFS in the Field
Both Storage Spaces and ReFS, as version 1.0 features, should be thoroughly tested in a lab environment before being deployed in production. There have been reports of ReFS volumes becoming inaccessible when they are filled to capacity, which is hardly the desired effect for a resilient file system.
While I expect that any teething problems will be fixed in Windows Server 2012 R2, make sure that you don’t get caught out, and test properly before deployment. Backup is also an important consideration. Not all backup software supports ReFS, so you need to check with the vendor of your backup solution to make sure you can protect ReFS volumes.
Some server applications either aren’t suited for deployment on ReFS volumes or aren’t compatible with some ReFS features. So before you use ReFS volumes for anything other than a file server volume, make sure you check that the application you intend to deploy has official ReFS support.