winntfs

Caveat: While efforts are made to make the content accurate, you peruse the contents of this blog at your own risk and responsibility. Any actions you take, or do not take based upon the blog contents are also your own responsibility.

Microsoft has strived to improve NTFS resiliency and availability through the various versions of Windows. This post focusses on one aspect: the availability of an NTFS volume when corruption is detected.

Prior to Windows Server 2008 R2, when an NTFS volume corruption is detected, the volume is taken offline and a process known as Chkdsk run to fix the corruption. The amount of time Chkdsk took to run was somewhat proportional to the number of files and directories within the NTFS volume. Thus smarter administrators sized NTFS volumes in a way that limited the maximum amount of files and directories within a given volume. For some corporations, this meant additional NTFS volumes with the associated management overhead. Starting with Windows NT4 and up to Windows 2008, Microsoft invested in efforts to reduce the amount of time it took to run Chkdsk.

With Windows Server 2008 R2, Microsoft changed tack and focused on improving NTFS volume availability by:

1. Further reducing the amount of time it took Chkdsk to run. In particular, this was done by reading NTFS meta data in bigger chunks and by better caching it, thus avoiding disk IOPS. Note that most of the time spent in Chkdsk is scanning the volume to detect issues, rather than in actually fixing the issues. This is where the time taken to run Chkdsk being proportional to the number of files & directories arises from.
2. Reducing the frequency with which Chkdsk needed to run by better detection of whether the volume was corrupted or not
3. Fixing at least some of the corruption issues without taking the volume off line, a process Microsoft termed “self healing”

Windows 8 takes this logical progression a step further

1. Scanning to detect errors is done while the volume is online and available.
2. As in step 3 above, self healing fixes some of the corruption issues. Indications are that a further set of errors is fixed by self healing in Windows 8 as compared to prior versions of Windows
3. The errors that cannot be corrected are logged
4. The volume is taken offline and the errors identified in phase C are corrected. This implies the volume is unavailable only for the duration taken to fix the errors logged in phase C.
5. In rare instances, the scanning determines that the corruption is too serious and needs a full offline scan, just as in Windows Server 2008 R2 and earlier versions of Windows.

Diagram 1 is a slide from a talk at the Windows 8 BUILD conference and the whole slide deck is available at this link

The item to note from the diagram is that the amount of time taken to fix a corrupted volume is now independent of the number of files and directories within the volume with one caveat. The caveat is that the corruption is not of an extremely serious nature – those still require the old style full scan while the volume is unavailable.

Microsoft now supports NTFS volumes of up to 24TB in size with Windows 8 and effectively, the number of files and directories within a given volume may also be increased without fear of the volume being unavailable for a long time due to corruption.

The changes in NTFS imply that an NTFS volume has more states in Windows 8 compared to prior versions of Windows. Tables 1 and 2 summarize the NTFS volume states in Windows 8 and prior versions of Windows

Table 1 Windows Server 2008R2/Windows 7 and earlier version of Windows NTFS volume states

 Table 2 Windows 8 NTFS Volume states

 Note that NTFS volumes are still “compatible” – you can take an NTFS volume created with prior versions of Windows and mount it on a Windows 8 system. You can also take an NTFS volume created with Windows 8 and use it with earlier versions of Windows.