The Master File Table (MFT) is perhaps the best known metadata file in an NTFS file system. Essentially it works as a “table of contents” for all the files on your volume describing attributes such as file name or the location of the file extents on a volume, and in some cases part of a file’s data as well (in some cases, all of file’s data). For every file, there exists at least one record (standard – 1KB in size) in the MFT for a file. When the attributes (e.g. data) of a file, an attribute could also mean the actual data itself (not just descriptors), could not fit in the 1KB record, it is written on the disk outside the MFT. These file attributes, typically the file’s data, are known as non-resident attributes. Non-resident describes the fact that they do not reside wholly in the MFT (where resident attributes* define the exact opposite).
As more files are added to an NTFS volume, additional records are created within the MFT to define those files. As files are deleted from a volume the space they occupied in the Master File Table (the file’s former record) is marked as available for use, but it is not deleted. Unlike some tools designed for databases or virtual disks, there is no tool or native action to shrink the MFT down to only the actual “in use” records. In essence this means the MFT can grow but will never shrink.
Microsoft file system developers thought ahead as they initially created the file system. They wanted to mitigate fragmentation of this key metadata file. They implemented an extension to this MFT file for future growth. The design they devised is known as the MFT reserved zone. It is a reserved area of free disk space located at the end of the currently allocated MFT space. As new records need to be created, the design was that they would expand into this reserved area, not randomly elsewhere on the disk, and hence not fragment the expanded MFT file.
Up through Windows 2000, this reserved area was relatively fixed, though in Win2K, you could edit the size. In most all cases the reserved zone would go unused and eventually allow for allocation of non-resident attributes as all other free space on a volume, other than the MFT reserved space, is filled up. If that occurred, the likelihood of the MFT fragmenting becomes almost a sure bet.
In Windows XP the behavior of the reserved zone changed. It went from being a hard coded percentage of the volume (default of 12.5%), to a dynamic extension called, by Microsoft, an “NTFS internal hint”. While Diskeeper received information on this change early in XP’s development, little data has been published on this from Microsoft. Given that we are talking about file system minutia that few care about or even need to be aware of, I can’t blame them.
That takes me, finally, to the purpose of this blog!
As I mention all too frequently, I frequent online technical forums and help out PC enthusiasts by sharing what I have come to learn or have researched about Window’s file systems. I have noticed, in numerous forums, questions regarding the “disappearance of the reserved zone” on Windows XP clients.
Many users, possibly well familiar with Windows 2000 or adroitly attuned to XP over a period time, notice that the reserved space on XP volumes shrinks or disappears from views in a Diskeeper analysis (or that of the built-in defragmenter). While almost all note it has not affected their performance (it would not) there is understandably a concern as this is a change from what they are familiar with.
As empirical evidence presented by these users would suggest, it is not a performance issue, and is perfectly normal.
If you are curious as to the current size of this reserved zone on your NTFS volumes you can use fsutil.exe (file system utility), or for easier-to-read information (i.e. not in hexadecimal!), use NTFSinfo.exe from Microsoft Sysinternals https://docs.microsoft.com/en-us/sysinternals/downloads/ntfsinfo
*Accessing resident attributes is much faster than accessing non-resident attributes. That is because the MFT record has to be accessed irregardless when accessing a file. If the request does not have to extend past the file record in the MFT to non-resident extents, that translates to less seek time (mapping extents) and disk head movement (retrieving data from the disk).