Fragmentation of Master File Table in NTFS volumes

Hi all.

Just out of curiosity, I wanted to check if MFT (Master File Table) on NTFS volume was defragmented and how badly.

My purpose to check MFT defragmentation was to decide whether it would be better, if possible, to increase the size of MFT in a given Windows 11 installation.

I found a Microsoft document on how to check MFT: How NTFS reserves space for MFT - Windows Server

I ran the 'dir /a $Mft' command in a command prompt window run as admin as documented in the Microsoft document, it did not yield any result except that it gave me the 'Volume Serial Number' and a 'File Not Found' message.

Then I found another Microsoft document: Contig - Sysinternals

Here I understood Contig.exe would give better results. But I still can't understand the output of Contig.exe. The following screenshot is the output of Contig executable on Windows 11 volume:



Does anyone have anything else to add here ?

Here is the full list of Contig.exe switches:

If you're using an SSD fragmentation has very little impact on performance.

suatcini54 said:

Does anyone have anything else to add here ?

Click to expand...

I'm a firm believer in the old adage "if it ain't broke, don't fix it." But The NTFS reserves a portion of the disk space as the "MFT zone" to ensure the MFT can grow without becoming fragmented.

Thank you for your contributions.

What I learned is,

1) MFT size is fixed and cannot be changed after Windows is installed. If one wants to change the size, this must be done during early stages of Windows installation just after formatting. Default size is 12.5% of Windows drive. set by the following registry value.

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem]
Value name="NtfsMftZoneReservation"
Data type=REG_DWORD
DATA=1 (12.5%) or 2 (25%) or 3 (37.5%) or 4 (50%)

If Data is not specified or wrong data entered, it is taken as 1 which corresponds to 12.5% of Windows drive. After Windows is installed, the Data of this registry value is shown as 0.

2) Fragmentation may happen on any disk type (SSD or platter drives) and affect Windows, but on SSDs its effect may be much too negligible.

3) I installed Windows 10 on a new drive (PCIe NVMe type) in July 2019 and updated Windows 10 and then Windows 11 many many times till now, including what is called "dirty installation". I can't tell how much fragmentation has happened in my MFT zone with Windows built-in tools. I tried to determine fragmentation with the method given in one of the MS Articles but I couldn't.

Number 3 above was the basis of my starting a thread.

Thanks again to those who responded.

You can defrag the $Mft withcontig64 $Mft, butcontig64 $Bitmapgives Access Denied even if you try to run it in an elevated command window, and, $Mft::$BITMAP is not to be confused with $Bitmap.

$Mft::$BITMAP is the internal bitmap that marks which MFT entries are in use. As files are created and deleted, this stream gets updated constantly. It is an attribute stream of $Mft. If the MFT grows frequently—which can happen typically on a database server with lots of heavy I/O—then the $Mft::$BITMAP stream can fragment, especially if the reserved MFT zone becomes exhausted. Although it's possible, it’s usually not severe enough to cause noticeable slowdowns, albeit in edge cases—like very large volumes with millions of files—it could lead to slightly increased I/O latency when allocating or freeing MFT records.

Whereas $Bitmap is a volume-level metadata file that tracks which clusters on the entire volume are in use or free. Each bit represents a cluster: 1 means allocated, 0 means free. It’s essential for space management—when you create or delete files, NTFS updates $Bitmap to reflect the change. Although its size is based on the total number of clusters, NTFS doesn’t always allocate the entire $Bitmap file upfront. It may allocate just enough to cover the currently addressable clusters and then extend the file incrementally as needed—especially on very large volumes or when the file system was created with lazy initialization. It also means that this file can get fragmented even if you never resize the partition. Although it is unusual, it can happen if:

• The volume is nearly full and NTFS has to extend the file into non-contiguous space.
• There’s heavy churn in allocation metadata (e.g. lots of file creation/deletion on a nearly full disk).
• The volume was originally created with poor layout or has suffered from long-term fragmentation elsewhere.

That said, fragmentation of the $Bitmap file usually only becomes a concern when trying to shrink a partition—because the last fragment might sit near the end of the volume, blocking the shrink operation.

The $Mft::$DATA stream is the core data stream of the Master File Table (MFT)—and it’s where NTFS stores the actual file records for every file and directory on the volume. If the MFT becomes fragmented, this stream gets split across the disk. It is whatcontig64 $mftdefrags, and, AFAIK defragging the $Mft::$BITMAP stream and/or the $Bitmap file can only be done at boot time, which also helps to explain (at least in part) why tools like UltraDefrag 14 have a boot time interface.

The bottom line is that, for the average user, none of it should matter. You certainly won't see a loss in performance that can be attributed solely to the MFT getting split up into a (reasonably low) number of fragments. Even in situations when this blocks you from shrinking the partition, you should still be able to use MiniTool Partition Wizard Portable to get the job done with very minimal effort anyway in the first place.

@hdmi Thank you very much for your taking the time to give a very detailed explanation. It is much appreciated.

Today I ran another config64 command on $MFT volume. This is what I got:



When I ran the same command on June 19 (seven days ago post #1), I got 3 frags/file. Today I got 2 frags/file. That's a move in the right direction by my PC.

Does this MFT fragmentation actually hurt performance? I agree with @hdmi that it's unlikely to see negative impact on a home PC, compared to a busy server which can create huge volumes of new files.

In my years as a Windows admin, I didn't hear many other IT admins complain you have to track this statistic.

I can't speak to contig, but hopefully it's smart enough to use trim and not actually defrag a SSD. Defrag can severely reduce the life of a SSD.

garlin said:

Does this MFT fragmentation actually hurt performance? I agree with @hdmi that it's unlikely to see negative impact on a home PC, compared to a busy server which can create huge volumes of new files.

In my years as a Windows admin, I didn't hear many other IT admins complain you have to track this statistic.

Click to expand...

Frankly speaking, I am not a heavy computer user. Being such a user, I haven't experienced any degradation in performance. And most probably, I wouldn't feel it even if there happened to be severe fragmentation in MFT zone. But I installed on this PC many updates, beta builds, dev builds over the years. That's why I wanted to see if any MFT fragmentation took place in my PC and how bad. To this end, I looked into MS documentation and tried to check fragmentation state of my PC. Unfortunately, as I explained in my first post I couldn't get any satisfactory results out of MS's own tools. Then I tried config64.exe from Sysinternals, which gave me something I could use.

Now it seems that MFT takes care of itself own its own. Otherwise, I would use 25% for MFT volume in my next clean installation.

@hdmi Thanks. That was the first MS article I had read. I ran the dir /a $MFT command as advised in the article but I got a file not found message. That's why I searched further and found contig64.exe from Sysinternals.



Have a nice day or night. It's night in here.

Try running defrag c: /a /u /v /h instead.

hdmi said:

Try running defrag c: /a /u /v /h instead.

Click to expand...

Thanks for the tip.

I ran the command and it returned a detailed analysis of the system. MFT size appeared to be 1.28 GB. MFT volume should have by definition around 16 GB (12.5% of Windows installation). This means I still have plenty of free space. No need to increase the size in my next Windows clean installation if my interpretation is correct.

Thanks again.