Windows Administration: NTFS and ReFS Filesystems
scottalanmiller last edited by scottalanmiller
Since Windows NT first released, one of its key components is the ever evolving NTFS file system. NTFS and its features have been core to the Windows NT experience, which includes family members like Windows NT 3.1, NT 4, Windows 2000, XP, 2003, 2008, 2012 and the current Server 2016. Starting in 2012, Microsoft added an additional enterprise filesystem to the Windows NT family: ReFS. With the addition of ReFS to the Windows NT family, Windows is now much more like most UNIX operating systems in providing administrators with multiple file systems filling different needs. This, however, is a new technical challenge for Windows Administrators because there have never been choices in the Windows world previously and it is very common for ReFS to mistakenly be thought of as a successor to NTFS when, in fact, it is not at all and is actually a complimentary file system.
NTFS is the standard filesystem for Windows and the appropriate choice for most use cases. ReFS cannot even be used for the main "C" drive as it is not bootable like NTFS. ReFS was designed to be the Windows answer to UNIX filesystems like ZFS, BtrFS and HammerFS.
NTFS is the more general purpose, more broadly applicable filesystem while ReFS is designed for use for Hyper-V storage and is expected to be used in conjunction with Storage Spaces.
The most common use cases are for NTFS to be used on top of hardware RAID while ReFS has built in software RAID that is often assumed to be used.
NTFS has more features than ReFS, big unique features include deduplication, compression, hard links, transactional NTFS, certain encryption types (EFS) and quotas. Some of these are rather significant. In most use cases, NTFS is also more performant than ReFS is. The benefits of ReFS are few and are only applicable under very specific conditions, conditions which at his time are generally warned against as being rather nascent and untested. It is not intended to replace or compete with NTFS but to fill a specific role for which NTFS is poorly suited.
For all intents and purposes, Windows Admins should be using NTFS in nearly all use cases, so much so that ReFS has little need to even be considered or discussed outside of pure curiosity in that world. Windows desktops and servers must run off of NTFS primarily and have little, if any, reason to even look to ReFS as it is often a pure negative in that environment.
In the Hyper-V virtualization world, ReFS has an important role to play but even there, only in specific circumstances and conditions - ones that remain the exception, not the rule. But it would behoove Hyper-V Administrators to familiarize themselves with ReFS to prepare them for an understanding of when ReFS is appropriate and when NTFS is appropriate.
When in doubt, when there is any question, simply choose NTFS. NTFS is the safe choice for speed, reliability, features and maturity.
Also, because ReFS is so new and because it trusts itself and other layers to never fail, it is poorly prepared to handle situations in which there has been a failure. From Wikipedia:
Issues identified or suggested for ReFS, when running on Storage Spaces (its intended design), include:
Adding thin-provisioned ReFS on top of Storage Spaces (according to a 2012 pre-release article) can fail in a non-graceful manner, in which the volume without warning becomes inaccessible or unmanageable. This can happen, for example, if the physical disks underlying a storage space became too full. Smallnetbuilder comments that, in such cases, recovery could be "prohibitive" as a "breakthrough in theory" is needed to identify storage space layouts and recover them, which is required before any ReFS recovery of file system contents can be started; therefore it recommends using backups as well.
Even when Storage Spaces is not thinly provisioned, ReFS may still be unable to dependably correct all file errors in some situations, because Storage Spaces operates on blocks and not files, and therefore some files may potentially lack necessary blocks or recovery data if part of the storage space is not working correctly. As a result, disk and data addition and removal may be impaired, and redundancy conversion becomes difficult or impossible.
Because ReFS was designed not to fail, if failure does occur, there are no tools provided to repair it. Third party tools are dependent on reverse engineering the system and (as of 2014) few of these exist.
These issues are incredibly serious as it means that there is significant concern as to the viability of ReFS in the one scenario under which it is intended to be used.
Dashrender last edited by
Interesting, nice write-up. Thanks
travisdh1 last edited by
@scottalanmiller Yet another article that made it into my standard reference links. Got anymore hiding in that noggin of yours?
Dashrender last edited by
I've read about ReFS, but didn't realize what it's purpose was. From what I did read, it was pretty obvious that it wasn't meant as a full on replacement for NTFS, but I didn't understand anything more.
This writeup should be a standard sorta How-to about ReFS.
Reid Cooper last edited by
Thanks for making a summary of this. Much easier to see when and where each makes sense.
iroal last edited by
Perfect timing, an ReFS thread just cropped up: https://community.spiceworks.com/topic/1908211-refs-vs-zfs
Obsolesce last edited by
@scottalanmiller SWEET write up SAM!
Now I don't have to type it out every time the question is brought up... I'll just link to this.
Will save me so much time.