ReFS
Sign in to saveAlso known as Resilient File System, Protogon, Microsoft ReFS
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.
Key facts
- File system.developer
- Microsoft
- File system.name
- ReFS
- File system.full_name
- Resilient File System
- File system.directory_struct
- B+ tree
- File system.max_volume_size
- 35 petabytes by Windows; 2 bytes with 16KB cluster size (2 × 16 × 2) in theory
- File system.max_file_size
- 35 petabytes by Windows; 2−1 bytes in theory
- File system.attributes
- Yes
- File system.compression
- No
- File system.data_deduplication
- Yes, since v3.2 debuting in 2016 v1709
- File system.introduction_os
- Windows Server 2012
- File system.copy_on_write
- Yes
via Wikipedia infobox
Wikidata facts
- Image
- Resilient File System.png
Show 1 more fact
- publication date
- 2012-08-01
via Wikidata · CC0
~18 min read
Article
19 sectionsContents
- Comparison with NTFS
- Major new features
- Improved reliability for on-disk structures
- Built-in resilience
- Compatibility with existing APIs and technologies
- NTFS features missing from ReFS
- Implementations
- History
- Server 2016
- Server 2022
- Server 2025
- Server vNext
- Versions
- Known problems
- Comparison with other file systems
- Reverse engineering and internals
- See also
- References
- External links
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 problems that had become significant over the years since NTFS was conceived, relating to changes in data storage requirements. 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 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.