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.
ReFS uses B+ trees for all on-disk structures, including all metadata and file data. Metadata and file data are organized into tables similar to a relational database. The file size, number of files in a folder, total volume size and number of folders in a volume are limited by 64-bit numbers; as a result, ReFS supports a maximum file size of 16 exabytes, a maximum of 18.4 × 1018 directories and a maximum volume size of 1 yottabyte (with 64 KB clusters) which allows large scalability with no practical limits on file and directory size (hardware limits still apply). Free space is counted by a hierarchical allocator which includes three separate tables for large, medium, and small chunks.
ReFS employs an allocation-on-write update strategy for metadata, which allocates new chunks for every update transaction and uses large IO batches. All ReFS metadata have 64-bit checksums which are stored independently. The file data can have an optional checksum in a separate "integrity stream", in which case the file update strategy also implements allocation-on-write; this is controlled by a new "integrity" attribute applicable to both files and directories. If file data or metadata become corrupt, the file can be deleted without taking the whole volume offline for maintenance, and then be restored from the backup. As a result of built-in resiliency, administrators do not need to periodically run error-checking tools such as CHKDSK when using ReFS.
ReFS resiliency features enhance the mirroring feature provided by Storage Spaces and can detect whether any mirrored copies of files become corrupt using the data scrubbing process, which can be enabled optionally,  periodically readd all mirror copies and verifies their checksums, then replaces bad copies with good ones.
In the subsequent implementation of ReFS in Windows 8.1 64-bit and Server 2012 R2, the file system reacquired alternate data streams 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:
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.
Even when Storage Spaces is not thinly provisioned, ReFS may still be unable to dependably correct all file errors in some situations, because Storage Spaces operates on blocks and not files, and therefore some files may potentially lack necessary blocks or recovery data if part of the storage space is not working correctly. As a result, disk and data addition and removal may be impaired, and redundancy conversion becomes difficult or impossible.
Because ReFS was designed not to fail, if failure does occur, there are no tools provided to repair it. Third party tools are dependent on reverse engineering the system and (as of 2014) few of these exist.
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. ZFS (used in Solaris and FreeBSD, among others) was widely criticized for its comparatively extreme memory requirements of many gigabytes of RAM for online deduplication, which ruled it out from a large number of medium and smaller systems. However, turning off online deduplication on ZFS, as this feature is unsupported in ReFS, yields a more even comparison between the two file systems since ZFS then has a memory requirement of only a few hundred megabytes. Offerings such as Drobo used 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, 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.