ReFS: The next generation file system (Part 1)
Windows 2012 is an operating system that is built for the cloud. A key characteristic of the cloud is seamless scalability. Hyper-V 2012 is certainly is a big feature of the Windows Server 2012 portfolio that is going to enable cloud deployment. But to fuel and sustain the scale of the cloud, the storage that enables this growth also needs to scale seamlessly. Â Windows 2012 (and even the client operating system Windows 8) tout the release of a new file system called ReFS (Resilient File System) that not only scales, but also provides the needed robustness even if the underlying infrastructure like power were to fail.
We will cover this file system in a series of posts. This one covers an introduction to the file system.
NTFS (New Technology File System) has been the default file system for the Windows operating system for over a decade now. (closing in on two decades actually). While NTFS is a very feature rich file system, supporting security using ACLs, compression, encryption, multiple data-streams and many more, it does lack the robustness and resilience to power failures and mechanical failures. In addition, to perform maintenance on the volume due to any corruption, the entire volume is inaccessible to check and fix the on-disk metadata structures.
Given that Windows Server 2012 was built for large scale deployments, primarily the cloud, the storage stack had to be revisited and largely reinvented to increase the performance and resilience of deployment.
As mentioned in Microsoft’s blog here, the goals behind ReFS were as follows:
- Ensure Application Compatibility: Maximize the compatibility with NTFS to ensure that existing applications and Windows software programming paradigms do not change.
- Increased integrity: As the name indicates, the file system is built to protect it from data loss by managing file system metadata such that corruption is localized. There is a proactive integrity scanner process, which is constantly scanning the file system metadata for corruption.
- Increased availability: In the event of a corruption, ReFS is designed to auto-correct the corruption. Also, in situations where the corruption cannot be automatically corrected, the file system provides means to salvage data online, thus requiring no downtime to the entire file system while the localized corruption is corrected.
- Increased scalability: With cloud deployments as a goal, the file system and the storage stack has to scale to Exabytes. ReFS has the following limits which provides such scalability.
| Attribute | Limit based on the on-disk format |
| Maximum size of a single file | 2^64-1 bytes (16 Exabytes) |
| Maximum size of a single volume | Format supports 2^78 bytes with 16KB cluster size (2^64 * 16 * 2^10). Windows stack addressing allows 2^64 bytes |
| Maximum number of files in a directory | 2^64 |
| Maximum number of directories in a volume | 2^64 |
| Maximum file name length | 255 unicode characters |
| Maximum path length | 32K |
| Maximum size of any storage pool | 4 PB |
| Maximum number of storage pools in a system | No limit |
| Maximum number of spaces in a storage pool | No limit |
As I sign off from this post, one point I would like to highlight is that ReFS is compliant with the VSS infrastructure, which is the back bone for backup applications to perform a crash- and file system consistent backup. Unitrends recently announced support for Windows Server 2012 and ReFS volumes can be protected with flexible backup strategies like Incremental forever with dynamic synthetic full backups.
The following sets of posts will dive deeper in to the guts of ReFS. So stay tuned.
