ReFS
Resilient File System (ReFS) is a proprietary file system developed by Microsoft, introduced in 2012 with Windows Server 2012, designed to maximize data availability, scale efficiently to large datasets, and provide robust data integrity through resiliency to corruption.[1][2] It serves as an alternative to the New Technology File System (NTFS), focusing on modern storage needs in enterprise environments while integrating seamlessly with Windows technologies like Storage Spaces.[1] ReFS emphasizes resiliency by employing integrity streams with checksums to detect corruption in metadata and optionally in file data, enabling proactive scanning and repair without taking volumes offline.[1] When paired with Storage Spaces, it supports automatic online repair using redundant data copies and can salvage usable portions of corrupted files by removing affected elements from the namespace.[1] This approach eliminates the need for traditional disk-checking tools like chkdsk in many scenarios, enhancing operational continuity for large-scale deployments.[1] In terms of performance and scalability, ReFS supports mirror-accelerated parity layouts for balancing speed and capacity, block cloning for efficient virtual machine operations, and variable cluster sizes up to 64 KB optimized for sequential I/O workloads.[1] It is engineered to handle petabyte-scale volumes up to 35 PB and millions of terabytes across storage environments without performance degradation, making it suitable for high-capacity storage arrays and future innovations in data management.[1] While primarily targeted at servers, ReFS has seen expanded support in client versions like Windows 10 and 11 for specific use cases, such as resilient volumes, though NTFS remains the default for general-purpose storage.[3] Recent enhancements include file-level snapshots since Windows Server 2022, native file system encryption, and improved data deduplication with compression integration in Windows Server 2025 to further optimize storage efficiency.[1]Overview and Design Goals
Purpose and Key Objectives
The Resilient File System (ReFS) is a proprietary file system developed by Microsoft to enhance data resilience and scalability in enterprise storage environments.[1] Introduced in Windows Server 2012 under the development codename "Protogon," ReFS was designed primarily for server workloads, aiming to address limitations in handling massive data volumes and ensuring high availability without extensive administrative intervention.)[4] Key objectives of ReFS include supporting enormous storage capacities, with volumes scalable up to 35 petabytes (PB), to accommodate the growing demands of data-intensive applications across diverse hardware configurations.) It emphasizes automatic integrity checking through checksums on metadata and data, enabling online detection and repair of corruptions to minimize downtime and reduce risks associated with metadata failures.[1][5] This resilience is particularly tailored for virtualized setups, such as Hyper-V virtual machines, and integrated storage solutions like Storage Spaces Direct, where data protection is paramount over general-purpose consumer features.[1] ReFS targets enterprise scenarios focused on reliable data storage in servers and clustered environments, prioritizing robustness against hardware faults, power failures, and bit rot over broad compatibility.) As a more resilient successor to NTFS, it was intended to gradually supplant the older file system in server roles, providing a foundation for software-defined storage while maintaining backward compatibility where essential.[1][6]Core Architectural Principles
ReFS employs an allocate-on-write mechanism for metadata updates, akin to copy-on-write, which allocates new storage space for modified metadata rather than overwriting existing data in place. This approach enhances resilience by preventing partial writes during power failures or system crashes from corrupting the file system structure, as the old metadata remains intact until the new version is fully committed.[7][5] The file system utilizes B+-tree structures to organize file metadata, directories, and object IDs, enabling efficient indexing and retrieval while supporting scalability to petabyte-scale volumes. All metadata in these structures includes checksums to detect corruption, ensuring data integrity through proactive validation during reads and scrubs. Allocation units in ReFS are configurable at 4 KB (default) or 64 KB, with the larger size recommended for workloads involving large files to improve efficiency by reducing fragmentation and metadata overhead.[8][5][9] Critical structures avoid in-place modifications; instead, ReFS writes new versions of metadata and atomically references them, minimizing the risk of inconsistent states. This design aligns with ReFS's emphasis on atomicity for updates. Additionally, ReFS natively supports block cloning, which remaps logical clusters between files as a metadata operation to accelerate copies without duplicating data until modifications occur, and sparse files via Sparse VDL, allowing files to allocate disk space only for actual data while supporting larger apparent sizes. These features contribute to efficient storage management at the file system level.[8][10][1]Comparison with NTFS
Enhancements and New Capabilities
ReFS introduces significant improvements in data reliability over NTFS by implementing checksums for all metadata, enabling proactive detection and correction of corruptions without requiring offline repairs. Unlike NTFS, which relies on less robust integrity checks, ReFS mandates checksums on metadata structures, allowing the file system to identify and repair inconsistencies online. Additionally, integrity streams provide an optional mechanism to extend checksum protection to user data, validating file contents against corruption caused by hardware failures or bit rot. This feature ensures that data integrity is maintained even for critical workloads, with repairs occurring automatically in the background without the downtime associated with tools like chkdsk.[1][5][11] For built-in resilience, ReFS incorporates block cloning, which uses the FSCTL_DUPLICATE_EXTENTS control code to enable instant file copies by referencing existing data blocks rather than duplicating them, significantly accelerating operations like virtual machine checkpoint merges. This is facilitated through reparse points that redirect I/O to the original blocks, minimizing storage overhead and impact on performance. ReFS also supports tiered storage, dividing volumes into performance (typically SSD) and capacity (HDD) tiers to optimize access patterns, with real-time tier optimization automatically promoting frequently accessed data to faster tiers for improved latency and throughput. These capabilities enhance overall system resilience by reducing I/O bottlenecks and enabling efficient data placement in large-scale environments.[1][12][1] In terms of scalability, ReFS supports volumes up to 35 petabytes, far exceeding NTFS's practical limits of around 256 terabytes, making it suitable for massive data repositories. The file system's copy-on-write (CoW) mechanism for metadata updates minimizes fragmentation by avoiding in-place modifications, which preserves allocation efficiency over time and reduces the need for defragmentation in high-write scenarios. Furthermore, integrity scanning is accelerated through optimized checksum computations and background scrubbing, allowing ReFS to verify petabyte-scale volumes more efficiently than NTFS's traditional methods, often completing scans in hours rather than days for equivalent data sets. As of Windows Server 2022, ReFS supports file-level snapshots that create constant-time snapshots irrespective of file size. As of Windows Server 2025, ReFS includes native data deduplication to further optimize storage efficiency, similar to NTFS.[1][13][3][14] ReFS maintains broad compatibility with NTFS by supporting key APIs, including widely used Win32 interfaces for file operations, and preserving access control lists (ACLs) for security. While it omits some NTFS-specific features, ReFS extends compatibility with integrity streams as an additional attribute, allowing applications to opt into data validation without altering core behaviors. However, it does not support Encrypting File System (EFS) encryption, relying instead on volume-level or application-managed alternatives for data protection.[3][15][16] A notable enhancement in ReFS version 3.9, introduced in Windows Server 2019, is mirror-accelerated parity for Storage Spaces, which combines mirroring for high-speed writes with parity for capacity efficiency, achieving up to twice the performance of prior implementations by dynamically rotating data between resiliency modes in real time.[17][18]Omitted or Deprecated Features
ReFS intentionally omits several features present in NTFS to emphasize data integrity, scalability, and performance in large-scale storage environments. Notably, ReFS does not support file-level compression as implemented in NTFS, where individual files or directories can be compressed using the file system's built-in attribute; instead, ReFS relies on volume-level block compression introduced in Windows Server 2022 or third-party solutions for similar functionality.[1] Similarly, ReFS lacks support for the Encrypting File System (EFS), NTFS's native per-file encryption mechanism, directing users to BitLocker for volume encryption or external tools for file-specific protection.[19] These omissions stem from design decisions to avoid mechanisms that could complicate metadata management and increase corruption risks in resilient scenarios.[20] ReFS also excludes disk quotas, a core NTFS feature for enforcing storage limits on users or volumes via File Server Resource Manager.[1] Support for reparse points includes specific types such as symbolic links, directory junctions, and mount points, with restrictions on certain third-party tags that could introduce operational complexity.[20] Alternate data streams (named streams) are supported but with limitations, capped at 128 KB per stream and without renaming capabilities, differing from NTFS's more flexible handling.[21] These choices prioritize streamlined operations over legacy compatibility, reducing potential points of failure in high-resiliency setups.[20] Several features are deprecated or altered in ReFS to enhance efficiency. Updates to last access timestamps are disabled by default via the registry key RefsDisableLastAccessUpdate, similar to NTFS where they can be enabled via registry or fsutil, to minimize metadata writes and improve I/O performance.[22] ReFS forgoes a traditional boot sector, utilizing reserved space for boot-related data instead, which eliminates legacy boot code vulnerabilities but precludes direct booting.[20] USN journal support is provided but limited, recording changes without full NTFS-level granularity for certain operations like hard links, focusing on essential auditing without overhead.[22] This rationale centers on favoring resilience against corruption and optimizing for modern workloads, avoiding features that might compromise data durability or scalability.[1] The impacts of these omissions are significant for deployment: ReFS volumes are not bootable, necessitating NTFS for system partitions during Windows installations and limiting ReFS to data or auxiliary storage roles.[1] Applications dependent on omitted NTFS features may require compatibility layers, such as mounting ReFS under NTFS for hybrid scenarios, or migration to alternatives like integrity streams for partial data protection needs.[1]Implementations and Platform Support
Supported Windows Versions
ReFS was initially introduced in Windows Server 2012, where it provided full support for formatting and managing volumes, while client support in Windows 8 was limited to the Pro and Enterprise editions, allowing read and write access but requiring specific configurations for formatting.[1] Support expanded with subsequent releases, including full implementation in Windows Server 2016 (ReFS version 3.1), partial support in Windows 10 for advanced editions like Pro for Workstations and Enterprise, Windows Server 2019 (version 3.4), supported features in Windows 11 for editions like Pro for Workstations and Enterprise (with Dev Drive utilizing ReFS), and Windows Server 2022 (version 3.7).[1][23] Windows Server 2025 offers native ReFS support (version 3.14), including enhancements to data deduplication for improved storage efficiency (building on support introduced in Windows Server 2019), compatibility with hotpatching for reduced downtime during OS updates, and integration with iSCSI for enhanced storage connectivity in clustered environments. Note that as of November 2025, there have been reports of compatibility issues, such as high resource usage and freezing with certain iSCSI configurations; see the "Known Limitations and Issues" section for details.[14][14][24] On client versions of Windows, ReFS is not enabled by default and is primarily targeted at server workloads; enabling it for formatting requires manual activation through registry modifications or PowerShell commands like Enable-WindowsOptionalFeature for related features in supported editions.[25][26] ReFS volumes must be created on dynamic disks, Storage Spaces, or certified hardware configurations, with no direct in-place conversion from existing NTFS volumes—requiring a fresh format that backs up data beforehand.[1][27]| Windows Version | ReFS Version | Key Support Notes |
|---|---|---|
| Windows Server 2012 | 1.1 | Initial full server support; basic client read/write in Windows 8 Pro/Enterprise.[1] |
| Windows Server 2016 | 3.1 | Enhanced scalability and integrity features.[28] |
| Windows 10 (Pro for Workstations/Enterprise) | Varies (up to 3.x) | Partial; limited to Storage Spaces formatting.[29] |
| Windows Server 2019 | 3.4 | Deduplication support added.[30] |
| Windows 11 | Up to 3.14 | Supported in Pro for Workstations and Enterprise; Dev Drive uses ReFS.[26][31] |
| Windows Server 2022 | 3.7 | Improved compatibility with Storage Spaces Direct.[23] |
| Windows Server 2025 | 3.14 | Deduplication enhancements, performance optimizations; known iSCSI issues reported as of November 2025.[14] |