Файловая система ReFS в Windows Server 2012/R2 и её будущее в vNext
0 likes6,488 views
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.
Файловая система ReFS в Windows Server 2012/R2 и её будущее в vNext
- 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 ???
Editor's Notes
- #14: The key features of ReFS are as follows (note that some of these features are provided in conjunction with Storage Spaces).
- #15: Documentation has all three tables listed in a single table. Good to use as a cube note.
- #16: Documentation has all three tables listed in a single table. Good to use as a cube note.
- #17: Documentation has all three tables listed in a single table. Good to use as a cube note.