|Full name||Resilient File System|
|Introduced||1 August 2012 with Windows Server 2012|
|Max. volume size||1 yobibyte (280 bytes)|
|Max. file size||16 exbibytes (264−1 bytes)|
|Supported operating systems||Microsoft Windows|
|Website||Resilient File System Overview|
Resilient File System (ReFS), codenamed "Protogon", is a Microsoft proprietary file system introduced with Windows Server 2012 with the intent of becoming the "next generation" file system after NTFS.
ReFS was designed to overcome issues that had become significant over the years since NTFS was conceived, which are related to how data storage requirements had changed. The key design advantages of ReFS include automatic integrity checking and data scrubbing, removal of the need for running chkdsk, protection against data degradation, built-in handling of hard disk drive failure and redundancy, integration of the RAID functionality, a switch to copy/allocate on write for data and metadata updates, handling of very long paths and filenames, and storage virtualization and pooling, including almost arbitrarily sized logical volumes (unrelated to the physical sizes of the used drives).
These requirements arose from two major changes in storage systems and usage — the size of storage in use (large or massive arrays of multi-terabyte drives now being fairly common), and the need for continual reliability. As a result, the file system needs to be self-repairing (to prevent disk checking from being impractically slow or disruptive), along with abstraction or virtualization between physical disks and logical volumes.
ReFS was initially added to Windows Server 2012 only, with the aim of gradual migration to consumer systems in future versions (although modifications were quickly developed by enthusiasts for the latter). The initial versions removed some NTFS features, such as disk quotas, alternate data streams, and extended attributes, causing concern among onlookers.[who?] Some of these were re-implemented in later versions of ReFS.
In early versions (2012–2013), ReFS was similar or slightly faster than NTFS in most tests, but far slower when full integrity checking was enabled, a result attributed to the relative newness of ReFS. Pre-release concerns were also voiced by one blogger over Storage Spaces, the storage system designed to underpin ReFS, which reportedly could fail in a manner that prevented ReFS from recovering automatically.
Some NTFS features are not implemented in ReFS. These include object IDs, 8.3 filename, NTFS compression, Encrypting File System (EFS), transactional NTFS, hard links, extended attributes, and disk quotas. ReFS does not itself offer data deduplication. In addition, Windows cannot be booted from a ReFS volume. Dynamic disks with mirrored or striped volumes are replaced with mirrored or striped storage pools provided by Storage Spaces; however, automated error-correction is only supported on mirrored spaces.
Support for alternate data streams was initially not implemented in ReFS. In Windows 8.1 64-bit and Server 2012 R2 the file system reacquired support for alternate data streams, with lengths of up to 128K, and automatic correction of corruption when integrity streams are used on parity spaces. ReFS had initially been unsuitable for Microsoft SQL Server instance allocation due to the absence of alternate data streams.
As of March 2015, a review of the state of ReFS on WIndowsNetworking.com stated that:
"You can’t (at least at this time) boot Windows from an ReFS volume and the first versions of ReFS don’t include file-level compression and encryption, disk quotas or hard links, all of which are advantages of NTFS over the FAT file systems. Note that ReFS does support sparse files, reparse points, case-sensitive file names and Unicode in file names and perhaps most important, it preserves and enforces access control lists (ACLs).
"It’s obvious that ReFS in its current iteration is not a replacement for NTFS ... because some applications that rely on specific NTFS features might not work with ReFS [... however...] Storage of most conventional data doesn’t require the specific NTFS features that aren’t supported by ReFS and so ReFS can handle that duty nicely. Its primary use case is on file servers that store extremely large amounts of data. It has data integrity and recovery mechanisms built into the file system, as well. That means those tools that are designed to detect and repair file corruption in other file systems aren’t necessary, so their incompatibility with ReFS isn’t really an issue. Additionally, although ReFS doesn’t support file level (Encrypting File System) encryption, BitLocker can be used to protect ReFS volumes so that’s not so much of an issue, either [...]
"ReFS has some distinct advantages over current reigning Windows file system NTFS, but it also has some drawbacks. It boasts self-healing powers, ability to repair files without down time, less risk that data will be lost when there’s a power failure (due to the way it writes metadata), and of course the ability to create huge volumes and files and even give those files names that are longer than 255 characters if you wish. But it’s not quite ready for prime time yet."
Issues identified or suggested for ReFS, when running on Storage Spaces (its intended design), include:
At the Storage Developer Conference 2015, a Microsoft developer presented enhancements of ReFS expected to be released with Windows Server 2016 and included in Technical Preview 4, titled 'ReFS v2'. It highlighted that ReFS now included capabilities for very high speed moving, reordering, and cloning of blocks between files (which can be done for all blocks of a file). This is particularly needed for virtualization, and is stated to allow fast provisioning, diff merging, and tiering. Other enhancements cover the redo log (for synchronous disk writes), parallelization, efficient tracking of uninitialized sparse data and files, and efficient 4k I/O. ReFS with File Integrity enabled also acts more like a log-structured file system, coalescing small random writes into large sequential ones for efficiency.[dubious ]
Other operating systems have competing filing systems to ReFS, of which the best known are ZFS and Btrfs, in the sense that all three are designed to integrate data protection, snapshots, and silent high speed background healing of corruption and data errors.
In 2014, a review of ReFS and assessment of its readiness for production use concluded that ReFS had at least some advantages over two of its main file system competitors.
In 2012, Phoronix wrote an analysis of ReFS vs Btrfs, a copy-on-write filesystem for Linux. Their features are similar, with both supporting checksums, RAID-like use of multiple disks, and error detection/correction. However, ReFS lacks deduplication, copy-on-write snapshots, and compression, all found in Btrfs and ZFS.