{"id":3219,"date":"2014-06-20T13:51:54","date_gmt":"2014-06-20T05:51:54","guid":{"rendered":"http:\/\/rmohan.com\/?p=3219"},"modified":"2014-06-20T18:14:02","modified_gmt":"2014-06-20T10:14:02","slug":"reasons-refs","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=3219","title":{"rendered":"Reasons ReFS"},"content":{"rendered":"

\"0216.5.jpg-550x0\"<\/a>Resilient File System (ReFS) is a new file system introduced in Windows Server 2012. Initially, it is being targeted for implementation as a file system that is primarily used for file servers. However, starting as the file system for a file server is just the beginning. Like its predecessor, NTFS, ReFS will begin as a file server system, then become a mainstream file system. Before long, we will all be using ReFS on our boot partitions.<\/span><\/p>\n

Resilient File System will likely replace NTFS completely within the next versions of Windows, and here are some reasons why you are going to really love the new file system.<\/p>\n

Comparing ReFS and NTFS Features<\/h2>\n

Although ReFS is a different file system, there are similar features between ReFS and NTFS. The easiest way to compare those is to look at the feature list side by side. Consider the following feature sets:<\/p>\n\n\n\n\n
\n

NTFS Features<\/strong><\/span><\/p>\n<\/td>\n

\n

ReFS Features<\/strong><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Supports Case-sensitive filenames<\/strong><\/p>\n

Preserves Case of filenames<\/strong><\/p>\n

Supports Unicode in filenames<\/strong><\/p>\n

Preserves & Enforces ACL’s<\/strong><\/p>\n

Supports file-based Compression<\/p>\n

Supports Disk Quotas<\/p>\n

Supports Sparse files<\/strong><\/p>\n

Supports Reparse Points<\/strong><\/p>\n

Supports Object Identifiers<\/p>\n

Supports Encrypted File System<\/p>\n

Supports Named Streams<\/p>\n

Supports Transactions<\/p>\n

Supports Hard Links<\/p>\n

Supports Extended Attributes<\/p>\n

Supports Open By FileID<\/strong><\/p>\n

Supports USN Journal<\/strong><\/p>\n<\/td>\n

\n

Supports Case-sensitive filenames<\/strong><\/p>\n

Preserves Case of filenames<\/strong><\/p>\n

Supports Unicode in filenames<\/strong><\/p>\n

Preserves & Enforces ACL’s<\/strong><\/p>\n

Supports Sparse files<\/strong><\/p>\n

Supports Reparse Points<\/strong><\/p>\n

Supports Open By FileID<\/strong><\/p>\n

Supports USN Journal<\/strong><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

 <\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n

Functionality<\/p>\n<\/td>\n

\n

NTFS<\/p>\n<\/td>\n

\n

ReFS<\/p>\n<\/td>\n<\/tr>\n

\n

Named Streams<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

OBJECT IDs<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

File System Compression<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

File System Encryption<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

TRANSACTIONS<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Sparse Files<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Hard Links<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Extended Attributes<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Quota<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Max size of a single file<\/p>\n<\/td>\n

\n

(264<\/sup>-1) bytes<\/p>\n<\/td>\n

\n

(264<\/sup>-1) bytes<\/p>\n<\/td>\n<\/tr>\n

\n

Max size of a single volume<\/p>\n<\/td>\n

\n

Roughly 256 TB<\/p>\n<\/td>\n

\n

Roughly 4.7 ZB (zettabytes)<\/p>\n<\/td>\n<\/tr>\n

\n

Max number of files in a directory<\/p>\n<\/td>\n

\n

No actual limitation<\/p>\n<\/td>\n

\n

2^64<\/p>\n<\/td>\n<\/tr>\n

\n

Max number of directories in a volume<\/p>\n<\/td>\n

\n

No actual limitation<\/p>\n<\/td>\n

\n

2^64<\/p>\n<\/td>\n<\/tr>\n

\n

Max file name length<\/p>\n<\/td>\n

\n

32K unicode characters<\/p>\n<\/td>\n

\n

32K unicode characters<\/p>\n<\/td>\n<\/tr>\n

\n

Max path length<\/p>\n<\/td>\n

\n

\u00a032K<\/p>\n<\/td>\n

\n

32K<\/p>\n<\/td>\n<\/tr>\n

\n

Boot to file system<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Supported on removable media<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Deduplication<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

WDS<\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Note also that ReFS only uses a 64KB cluster size, which means a lot of wasted space for disks with lots of small files. Since ReFS uses a Copy on Write mechanism, there’s a greater chance of fragmentation.<\/p>\n

\"Image<\/a><\/p>\n

\"0216.5.jpg-550x0\"<\/a><\/p>\n

Notice that key capabilities missing from ReFS as compared to NTFS are EFS encryption, quotas, and compression. BitLocker may be used for encrypting these volumes while EFS is not an option. Thus, when using ReFS, encryption doesn\u2019t need to be part of the file system. BitLocker satisfies the need for encrypting data on the volume as it encrypts the contents of the entire disk. Quotas may be managed outside the file system rather than through the file system like NTFS. Not supporting Hard Links is a key reason why you wouldn\u2019t use ReFS for a system disk; files in the system32 folder are really hard linked back into the WinSxS folder structure. You might think that ReFS would have data deduplication built-into the file system. The fact that it doesn\u2019t may not prohibit other components or third-party solutions from interfacing with ReFS through the API set provided.<\/p>\n

Command Line Directives for ReFS<\/p>\n

For those that are script fanatics (you know who you are), I\u2019ve written this section just for you. We all know that the need for scripting language happens all the time. Perhaps you\u2019re just creating re-creatable virtual environments for one reason or another\u2026and now you need to include the creation of some ReFS volumes. Below are some valuable commands including conventional and PowerShell examples.<\/p>\n

Formatting a ReFS Volume<\/p>\n

While this can be done from the UI quite easily by choosing ReFS as the file system in the drop down from the Format dialog, this is also easily done from the command line. Full format example below:<\/p>\n

Command-Line<\/p>\n

Format \/fs:ReFS J:<\/p>\n

PowerShell Equivalent<\/p>\n

Format-Volume \u2013DriveLetter J \u2013FileSystem ReFS -Full<\/p>\n

In fact, typical command line syntax and optional parameters apply. Therefore, if you want this to be a quick format, just append \/q to the above command line. However, you have the option to enable Integrity Streams for the volume. Note the following command:<\/p>\n

Command-Line<\/p>\n

Format \/fs:ReFS \/q \/i:enable J:<\/p>\n

PowerShell Equivalent<\/p>\n

Format-Volume \u2013DriveLetter J \u2013FileSystem ReFS \u2013SetIntegrityStreams $true<\/p>\n

The preceding command enables Integrity Streams on drive J: and performs a quick format. The \/i option offers you the ability to enable|disable this feature for the volume. If you enable this option, all files created on the volume will be configured with integrity. You may turn this off for individual files or folders using the Integrity command. However, know that if a file is non-empty and has data streams created with Integrity Streams, you cannot disable the feature for that file. You cannot change the integrity status for a file once the file contains integrity data streams. You could copy the file to another partition, delete the original, and then copy it back without Integrity Streams.<\/p>\n

 <\/p>\n

 <\/p>\n

<\/a>Features of Microsoft’s ReFS<\/h3>\n

The main focus of new features is resilience, for example, automatically correcting data errors. Verifying with checksum before the write commits, and thus avoiding “torn writes”; it works by allocate-on-write, which never updates metadata in-place, but rather writes it to a different area of the disk, rather like “shadow paging”.<\/p>\n