|Full name||Resilient File System|
|Introduced||1 August 2012 (Windows Server 2012)|
|Max. volume size||1 yottabyte|
|Max. file size||16 exabytes|
|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, related to how data storage requirements had changed. Its key design advantages are intended to include - automatic integrity checking and data scrubbing, removing the need for chkdsk and protecting against data degradation; built-in handling of hard drive failure and redundancy, including RAID and a switch to copy/allocate on write for data and metadata updates; very long path and filename handling; and storage virtualization and pooling, including almost arbitrary logical volume size (as distinct from the physical sizes of the disks used).
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, causing concern among onlookers, such as quota systems and extended attributes. Some of these were re-implemented in later versions of ReFS.
In its 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. Concerns were also raised over storage spaces, the storage system designed to underpin ReFS, which is able to fail in a manner that prevents ReFS itself from recovering.
Some NTFS features were removed and unsupported in the initial versions of ReFS. These included named streams, 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.
Features initially removed include:
Windows 8.1 (only in the 64 bit version) is the first client operating system to provide some support for ReFS.
ReFS was initially unsuitable for Microsoft SQL Server instance allocation due to the absence of alternate data streams. However, in Windows 8.1 and Server 2012 R2, ReFS reacquired alternate data streams and automatic correction of corruption when integrity streams are used on parity spaces.
Adding thin-provisioned ReFS on top of Storage Spaces (according to a 2012 pre-release article) can fail in a non-graceful manner, in which the volume without warning becomes inaccessible or unmanageable. This can happen, for example, if the physical disks underlying a storage space becomes too full. Smallnetbuilder comments that in such cases, recovery could be "prohibitive" as a "breakthrough in theory" is needed to identify storage space layouts and recover them, which is required before any ReFS recovery of file system contents can be started; therefore it recommends using backups as well.
Other issues identified or suggested for ReFS running on Storage Spaces (its intended design) include:
In 2014, a review of ReFS and assessment of its readiness for production use, concluded that ReFS had key advantages over two of its main file system competitors, insofar as ZFS (used in FreeBSD) was widely criticized for its comparatively extreme memory requirements of many gigabytes of RAM, which ruled it out from a large number of medium and smaller systems, while offerings such as Drobo use proprietary methods which have no fallback if the company behind them fails.
ReFS was also found to be capable of running slightly faster than NTFS in most tests. However with integrity checking enabled, ReFS was found to be greatly slowed, and to run "dismally", suffering "a huge hit on performance and very high latency"; benchmark testing shows around 90% slowdown. However, they also point out that ReFS is still very much a newcomer ("essentially a “1.0” feature that is rough around the edges") and has not had the time to reach maturity that file systems such as ZFS have had.
In 2012, Phoronix wrote an analysis of ReFS vs Btrfs, an experimental 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.