Major new features[edit]
Improved reliability for on-disk structures
ReFS uses
B+ trees for all on-disk structures, including all metadata and file data.
[2][14] Metadata and file data are organized into tables similar to a
relational database. The file size, number of files in a
folder, total volume size and number of folders in a volume are limited by 64-bit numbers; as a result, ReFS supports a maximum file size of 16
exbibytes (264−1 bytes), a maximum of 18.4 × 1018 directories and a maximum volume size of 1
yobibyte (280 bytes) (with 64
KiB clusters) which allows large scalability with no practical limits on file and directory size (hardware limits still apply). Free space is counted by a hierarchical allocator which includes three separate tables for large, medium, and small chunks.
Built-in resilience
ReFS employs an
allocation-on-write update strategy for metadata,
[2] which allocates new chunks for every update transaction and uses large
IO batches. All ReFS metadata have 64-bit checksums which are stored independently. The file data can have an optional checksum in a separate "integrity
stream", in which case the file update strategy also implements allocation-on-write for file data; this is controlled by a new "integrity" attribute applicable to both files and directories. If file data or metadata become corrupt, the file can be deleted without taking the whole volume offline for maintenance, and then be restored from the backup. As a result of built-in resiliency, administrators do not need to periodically run error-checking tools such as
CHKDSKwhen using ReFS.
Compatibility with existing APIs and technologies
ReFS supports only a subset of NTFS features, and only Win32 APIs that are "widely adopted"; but does not require new system APIs and most file system filters continue to work with ReFS volumes.
[2] ReFS supports many existing Windows and NTFS features such as
BitLocker encryption,
Access Control Lists,
USN Journal, change notifications,
[15] symbolic links,
junction points,
mount points,
reparse points,
volume snapshots,
file IDs, and
oplock. ReFS seamlessly integrates with
Storage Spaces,
[2] a
storage virtualization layer that allows data mirroring and striping, as well as sharing storage pools between machines.
[16] ReFS resiliency features enhance the mirroring feature provided by Storage Spaces and can detect whether any mirrored copies of files become corrupt using a
data scrubbing process,
[14] which periodically reads all mirror copies and verifies their checksums, then replaces bad copies with good ones.
Removed features[edit]
Some NTFS features are not implemented in ReFS. These include
object IDs,
8.3 filename,
NTFS compression,
Encrypting File System (EFS),
transactional NTFS,
hard links,
extended attributes, and
disk quotas.
[5][2][17] In addition, Windows cannot be booted from a ReFS volume.
[2] Dynamic disks with mirrored or striped volumes are replaced with mirrored or striped storage pools provided by Storage Spaces; however, automated error-correction is only supported on mirrored spaces.
Data deduplication was missing in early versions of ReFS.
[2], it was implemented in v3.2, debuting in Windows Server v1709.
[3]
Support for
alternate data streams was initially not implemented in ReFS. In Windows 8.1 64-bit and Server 2012 R2 the file system reacquired support for alternate data streams, with lengths of up to 128K, and automatic correction of corruption when integrity streams are used on parity spaces.
[18] ReFS had initially been unsuitable for
Microsoft SQL Server instance allocation due to the absence of alternate data streams.
[19]
As of March 2015, a review of the state of ReFS on
WIndowsNetworking.com stated that:
[20]
"You can’t (at least at this time) boot Windows from an ReFS volume and the first versions of ReFS don’t include file-level compression and encryption, disk quotas or hard links, all of which are advantages of NTFS over the FAT file systems. Note that ReFS does support sparse files, reparse points, case-sensitive file names and Unicode in file names and perhaps most important, it preserves and enforces access control lists (ACLs).
"It’s obvious that ReFS in its current iteration is not a replacement for NTFS ... because some applications that rely on specific NTFS features might not work with ReFS [... however...] Storage of most conventional data doesn’t require the specific NTFS features that aren’t supported by ReFS and so ReFS can handle that duty nicely. Its primary use case is on file servers that store extremely large amounts of data. It has data integrity and recovery mechanisms built into the file system, as well. That means those tools that are designed to detect and repair file corruption in other file systems aren’t necessary, so their incompatibility with ReFS isn’t really an issue. Additionally, although ReFS doesn’t support file level (Encrypting File System) encryption, BitLocker can be used to protect ReFS volumes so that’s not so much of an issue, either [...]
"ReFS has some distinct advantages over current reigning Windows file system NTFS, but it also has some drawbacks. It boasts self-healing powers, ability to repair files without down time, less risk that data will be lost when there’s a power failure (due to the way it writes metadata), and of course the ability to create huge volumes and files and even give those files names that are longer than 255 characters if you wish. But it’s not quite ready for prime time yet."
