In the third video in a series of five, storage expert Brien Posey walks users through Windows Server 2012 ReFS features, including why Microsoft chose to offer an alternative to NTFS and what this change means for resiliency and reliability. Read some of Posey's remarks below or view his presentation above to learn more.
Windows Server has existed in one form or another since the mid-'90s. Back then it was called Windows NT Server; and it's been evolving ever since.
The NTFS file system has been around for just as long as Windows Server has. And the new technology file system really isn't so new anymore. That isn't to say that NTFS is useless or that it's gone. NTFS is alive and well in Windows Server 2012.
However, Microsoft also created a new file system called ReFS. The acronym stands for the resilient file system; it is designed to be a next-generation replacement for NTFS.
What you might not realize is that ReFS is actually based on NTFS. When Microsoft created ReFS, it kept the NTFS components that worked and got rid of things that were not needed -- i.e., the components that weren't aging that well. Then the company took several drastic measures to greatly improve reliability.
View the rest of Brien Posey's WS 2012 tip series:
Video tip 1: Native iSCSI Target Software
Video tip 2: Native data deduplication capabilities
Video tip 4: Windows Storage Spaces
Video tip 5: Offloaded Data Transfer (ODX)
The main goal behind ReFS was to improve resiliency and reliability, especially in instances when a power failure happens. NTFS could sometimes be corrupted by power failures, and ReFS is specifically designed to protect against that.
The gist behind this new technique is that when a file is updated, the file itself is not immediately overwritten. Instead, ReFS allocates an unused portion of the disk and writes the new copy to that unused portion of the disk. That way, if the power failure occurs during the write operation then you've still got your original file.
If the power doesn't go out during the write operation, then the new file is successfully created and the old file is eventually deleted.
Write operations in the ReFS file systems are based on something called integrity streams. Another part of that is checksumming. The idea behind a checksum is that when you write data, you create a checksum and you write that checksum to the disk as well. Thus, you have this checksum value that you can use later on to verify that the data is still in a healthy state by comparing the data to the checksum that was based on the data.
Another thing that Windows Server 2012 ReFS does in the name of keeping your data healthy is to actively search for volume corruption -- and it does that by using the checksum data. What happens if corruption is detected? The portion of the volume where the corruption existed gets isolated so you're not writing data again to a portion of the volume that previously contained corrupt data. If you've got a physical problem with the underlying disk, then you're not attempting to store data on a portion of that disk that could be bad.
About the presenter:
Brien Posey is a regular SearchStorage.com contributor and a Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien was CIO for a national chain of hospitals and health care facilities. He also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.