ReFS is a new file system in Windows Server 2012 that is more resilient than NTFS. It uses techniques like checksums and copy-on-write to protect against data corruption. ReFS stores data in tables accessed through MinStore, providing improved scalability over NTFS. While missing some NTFS features, ReFS is best for large archives and virtual disk storage where high availability is important. It is optimized for use with Storage Spaces in future versions of Windows Server.

1. ФАЙЛОВАЯ СИСТЕМА REFS В
WINDOWS SERVER 2012/R2 И ЕЁ
БУДУЩЕЕ В VNEXT
A. Kibkalo

2. RESILIENCY FILE SYSTEM (REFS) (MNTFS)
What You Will Learn
After completing this lesson, you will be able to:
 Describe the issues around data corruption
 Define silent rot
 Explain the differences between ReFS and NTFS
2

3. RESILIENT FILE SYSTEM (REFS)
 Windows Server 2012 includes a new file system ReFS, short for Resilient File System.
 NOTE: Early internal documentation referred to ReFS as MNTFS before it was finally
named ReFS.
3

4. RESILIENT FILE SYSTEM (REFS), CONT’D
The main reason for the inclusion of a new file system is easy to understand when you look
at the simplified Windows storage stack.
4

5. RESILIENT FILE SYSTEM (REFS), CONT’D
 The file system rides along so high on the stack that there is just too much obfuscation
between it and the actual hardware.
 Until now, Microsoft has simply trusted that the hardware was doing what we told it to
do.
5

6. RESILIENT FILE SYSTEM (REFS)
So where has that trust gotten us?
6
Event ID 55
Source Ntfs
Description: The file system structure on the disk is corrupt and unusable. Please run the
CHKDSK utility on the volume C:.
Event ID: 51
Event Type: Warning
Event Source: Disk
Description: An error was detected on device DeviceHarddisk3DR3 during a paging
operation.
Event ID: 50
Event Type: Warning
Event Source: Ftdisk
Description: {Lost Delayed-Write Data} The system was attempting to transfer file data
from buffers to DeviceHarddiskVolume4. The write operation failed, and only some of the
data may have been written to the file.

7. RESILIENT FILE SYSTEM (REFS)
 What is worse, even if we can fix the problem, we rarely know what the cause was.
Often times it was actually ‘silent rot’.
 Silent rot, aka bit rot, is the silent data killer than is not widely talked about. It is like the
dirty little secret of the storage world. This could be a bit flip, i/o that was carried out
incorrectly, or just the magnetic media’s inability to hold a bit position.
7

8. BIT ROT I
 It has been our long held position to put the responsibility for maintaining data integrity
onto the storage vendor.
 This has not worked out well for us as it has put Microsoft in the uncomfortable position of
blame.
 The file system must to be able to assemble those blocks into the files that customers
need.
 So if a drive experiences a problem like silent rot, it isn’t seen until the file system is trying
to work with the corresponding block.
 The result is that we are left reporting the problem, and subsequently we are the ones
blamed for it.
8

9. BIT ROT II
 Storage solutions are not without error detection and correction capabilities of course.
However, as systems have increased in complexity, it has become plain that the current
methods of preventing silent rot have long since been insufficient.
 Some applications are already doing integrity checking for their data files. The problem
with this approach is that it is expensive and only helps the data files associated to the
applications that provide such checking. Silent rot can hit any file, not just the few that
are being protected by applications.
9

10. BIT ROT III
 The solution that would deliver the biggest blanket of protection would be to provide
additional error checking at the top layer that actually touches all files…the file system
layer.
 We are seeing this same approach in the new file systems of other technology leaders
such as Sun’s Zettabyte File System (ZFS) and Oracle’s B-Tree File System (BTrFS).
10

11. INTRODUCTION
 ReFS is a new resilient, efficient, and scalable Windows file system.
 It helps to protect data against lost, misdirected, and torn writes and latent data
corruption.
 It intelligently utilizes redundant data stores where available and can efficiently repair
data in order to keep volumes online for as long as possible.
 It can scale to the files, directories, and volumes of the future.
 It has an efficient I/O pattern that is suitable for the devices of the future, both small and
large.
 It is mostly backward compatible with Windows’ stalwart file system NTFS. Its data
resiliency features are mandatory for file system metadata and are optional for user
data, offering flexibility between performance and resiliency. In short, ReFS is a modern,
scalable, resilient copy-on-write file system.
11

12. REFS GOALS
 Maintain a high degree of compatibility with a subset of NTFS features that are widely
adopted while deprecating others that provide limited value at the cost of system
complexity and footprint.
 Verify and auto-correct data. Data can get corrupted due to a number of reasons and
therefore must be verified and, when possible, corrected automatically. Metadata must
not be written in place to avoid the possibility of torn writes.
 Optimize for extreme scale. Use scalable structures for everything. Don’t assume that
disk-checking algorithms, in particular, can scale to the size of the entire file system.
 Never take the file system offline. Assume that in the event of corruptions, it is
advantageous to isolate the fault while allowing access to the rest of the volume. This is
done while salvaging the maximum amount of data possible, all done live.
 Provide a full end-to-end resiliency architecture when used in conjunction with the
Storage Spaces feature, which was co-designed and built in conjunction with ReFS
12

13. REFS FEATURES
 Metadata integrity with checksums
 Integrity streams providing optional user data integrity
 Allocate on write transactional model for robust disk updates (also known as copy on
write)
 Large volume, file and directory sizes
 Storage pooling and virtualization makes file system creation and management easy
 Data striping for performance (bandwidth can be managed) and redundancy for fault
tolerance
 Disk scrubbing for protection against latent disk errors
 Resiliency to corruptions with "salvage" for maximum volume availability in all cases
13

14. NTFS VS REFS I
Functionality NTFS ReFS
Named Streams Yes No
OBJECT IDs Yes No
File System Compression Yes No
File System Encryption Yes (EFS) No
Transactions (TxF) Yes No
Short File Names Yes No
Sparse Files Yes No
File Table Yes (MFT) No
Hard Links Yes No
Extended Attributes Yes No
Quota Yes No
14

15. NTFS VS REFS II
Functionality NTFS ReFS
Max size of a single file (264-1) bytes (264-1) bytes
Max size of a single volume Roughly 256 TB Roughly 4.7 ZB
Max number of files in a directory No actual limitation 2^64
Max number of directories in a volume No actual limitation 2^64
Max file name length 255 characters 255 characters
Max path length 32K 32K
Boot to file system Yes No
Supported on removable media Yes No
Failover Cluster support Yes Yes
Deduplication Yes No
BitLocker encryption Yes Yes
Access-control lists Yes Yes
USN journal Yes Yes
Change notifications Yes Yes
15

16. NTFS VS REFS III
Functionality NTFS ReFS
Junction points Yes Yes
Mount points Yes Yes
Reparse points Yes Yes
Volume snapshots Yes Yes
File IDs Yes Yes
Oplocks Yes Yes
VSS snapshot support Yes Yes
Availability Server/Client Server only
Usable with WDS Yes No
Usable with new CSV Yes No
Usable with Branch Cache Yes No (Needs Object ID)
Usable with FCI Yes No (Needs Named Streams)
Usable with FRS Yes No (Hard blocks non NTFS)
Usable with DFSR Yes No (Hard blocks non NTFS)
No (Needs sparse files)
No (Needs Named Streams)
16

17. SCALABILITY
 NTFS has a size limit of 256 GB. ReFS scales to PB datasets.
 NTFS has performance issues with volumes that have millions of files despite the fact that
it supports storing billions of files. Because of the B+ tree data structure for ReFS
metadata, it does not suffer from the same performance hit when millions of files are on
the volume.
 Another issue with NTFS is the occasional need to take the volume offline to run CHKDSK.
While this has been improved in Windows Server 2012, ReFS has removed the need to run
CHKDSK entirely. In fact, you are actually blocked from running it.
17

18. INTEGRITY
On ReFS, file system metadata is always protected with integrity. That means if there is
corruption detected for file system metadata:
 Simple Space: the error will be logged
 Mirror Space: the error will be automatically corrected, assuming an alternate copy is
available/valid
 Parity Space: the error will be logged
18

19. INTEGRITY
User data is optionally protected with integrity. That means if there is
corruption detected for user data where integrity is enabled:
 Simple Space: the error will be logged
 Mirror Space: the error will be automatically corrected, assuming an
alternate copy is available/valid
 Parity Space: the error will be logged
19
Space Type User data Integrity Default Auto correction supported
Simple Disabled No
Mirror Enabled Yes
Parity Disabled No
For user data where integrity is not enabled the
behavior will be identical to NTFS.

20. INTEGRITY
To determine whether integrity is enabled the “Enabled” column
will display “True” when integrity is enabled.
20
PowerShell:
Get-FileIntegrity -FileName E:
For control over integrity, use the following Windows PowerShell:
Set-FileIntegrity
Get-FileIntegrity
Repair-FileIntegrity
Keep in mind that integrity only applies to ReFS. These Windows
PowerShell cmdlets will not function on NTFS volumes.

21. MINSTORE
 ReFS is entirely dependent upon MinStore to deliver on its goals. Without an
understanding MinStore, it will be extremely hard to understand the motivations,
rationale, and effect of the decisions made in the design of the file system.
 MinStore is a recoverable object store library that provides a key-value table interface to
its callers, implements copy-on-write (COW) semantics for modifications to those tables,
and optionally integrates with the Windows Cache Manager. In addition, it exposes a
namespace for table objects, a hierarchical allocator, and a transaction model.
21

22. MINSTORE, CONT’D
 On-disk structures and their manipulation are handled by the on-disk storage engine. As
an example, when NTReadRfile() is called, it is MinStore that provides VCN to LCN
mappings.
 ReFS is a hybrid of the NTFS implementation and MinStore. There are many details of the
design that are inherited from NTFS. As such, familiarity with the way that NTFS is
designed and implemented is useful, but not necessary.
22

23. MINSTORE, CONT’D AGAIN
 The following diagram outlines the application compatibility
behind ReFS and NTFS.
23
NTFS has an upper layer of APIs that the rest of
Windows can use to interface with the file system.
Below that is the on-disk store where files are
organized on the storage media.

24. MINSTORE, CONT’D YET ANOTHER TIME
 ReFS has a similar upper layer where nearly all of the same APIs are
supported. The fundamental difference is in the way that ReFS stores
its metadata and user data on the media.
24
Instead of just on-disk structures, ReFS's lower layer has
MinStore, which is comprised of the on-disk structures
and an in-memory component as well.

25. APIS NOT SUPPORTING REFS
 There is a long list of APIs that do not support ReFS. This is in the class documentation.
 Most of the APIs have to do with functionality that is not supported by ReFS
25

26. REFS INFORMATION IS STORED IN A SERIES OF TABLES
 An Object table will contain objects that point to a Directory table.
26

27. REFS INFORMATION IS STORED IN A SERIES OF TABLES
 The Directory table will contain a list of the file names associated with the directory. This
leads us to a File Metadata table.
27

28. REFS INFORMATION IS STORED IN A SERIES OF TABLES
 And finally individual file extents are defined in a File Extents table.
28

29. ON-DISK STRUCTURES
 Unlike the rigid nature of NTFS, the on-disk structures for ReFS are more fluid. NTFS taught
us that if we have such rigidly defined structures, the file system becomes very limited. It
is the intention to keep ReFS structures out of public hands so developers will not attempt
to manipulate the file system's raw sectors.
 That being said, here are some very general points of which you should be aware.
29

30. BOOT SECTOR
ReFS still has a boot sector but there is not much to it. Mostly it is just there for compatibility
with tools that identify file system type using the OEM ID string (shown here at offset 0x3).
30

31. SUPER BLOCK AND CHECKPOINTS
 A structure exists called the Super block. This is a read-only list of the locations of
'Checkpoints'.
 There are thee copies of the Superblock. Only one is in use. The only time the
Superblock changes is when the volume is extended or otherwise altered.
31

32. SUPER BLOCK AND CHECKPOINTS
 A Checkpoint record contains the location of the global structures and the checksums
necessary for validation.
 Multiple copies of a Checkpoint are written on the volume. This is to protect against
faults or corruption destroying all checkpoint records.
 Recovery is simply the identification of the most recent checkpoint record. Sequence
numbers are used to accomplish this.
Both superblock and checkpoint record contain their own respective checksums and a
clock so we know which one is more recent in event of a disagreement
32

33. POINTS OF CONCERN
 Fragmentation : Because of the COW nature of ReFS, it has a high potential for
fragmentation.
 Cluster size : ReFS has only one cluster size available to it, 64kb. This might lead to issues
with lost space when many tiny files are stored on the volume.
 Limitations : There are a number of limitations with ReFS as far as competing with NTFS. It
may be more reliable, but due to its limitations, it is not a good fit for everything that NTFS
current handles today. As an example, since ReFS does not support named data
streams it cannot be used with File Classification Infrastructure, as the file tags are stored
in alternate data streams.
 Identification : Poorly written tools that use the partition identifier as a method of
identifying a file system will have issues with ReFS as it identifies as NTFS (07). Some tools
will need to be updated to use the identification information in the boot sector instead.
33

34. BEST USES FOR REFS – WINDOWS SERVER 2012/R2
ReFS is best used when a highly resilient and continually available file system is needed that
is not bogged down in with the extra bells and whistles that NTFS provides.
A couple such examples would be:
 User data
 Archives of big data
 VHD libraries
34

35. BEST USES FOR REFS – WINDOWS SERVER VNEXT
 ReFS is optimized for Shared Nothing Storage Spaces for Live VM Storage
 Tuned for Hyper-V
 VHD(x) specific optimizations
 Alternate Data Streams support

36. VHD(X) SPECIFIC OPTIMIZATIONS
 Fast Fixed VHD(x) Disk Creation
 Fast VHD(x) Growth
 Fast VHD(x) Merge

37. REFS TECHNICAL PREVIEW LIMITATIONS
 Volumes can be accessed only from one build, which has formatted them
 Data is lost on upgrade to next builds
 Test deployments only

38. BEST REFS TESTING SCENARIO
 Shared Nothing Storage Spaces with (Get-Cluster).DASModeEnabled=1
 ReFS as file system for the virtual disk (Storage Space)
 Also works with existing storage

39. LESSON REVIEW
Topics covered in this lesson include the following:
 Introduction to the new file system, ReFS
 Problems that lead to the creation of ReFS
 Differences between ReFS and NTFS
39

40. QUESTIONS ???