MFT fragmentation

Hello all!

As I understand it, 12.5% is by default reserved for the MFT on a NTFS volume.

This translates into these values for my respective partitions:

C: - 1GB
D: - 3GB
E: - 1GB

I also understand that a MFT is always in at least two fragments since the one at the front of the volume can not be moved.

I´ve tried to figure out why the analyse function of the inherent WinXP defragmentation tool is reporting this:

C: - Total MFT size = 30MB, 20574 posts, 67% used and 5 fragments.

D: - Total MFT size = 9MB, 8809 posts, 99% used and 3 fragments.

E: - Total MFT size = 49kB, 35 posts, 71% used and 4 fragments.

I suspect that the percentage is how much of the "Total MFT size" that is actually used by the respective number of posts but I don´t understand how or why ...... ...... ?

Total MFT size is, in all cases, way below the reserved space. The "worst" case occupies less than 3% of it.

The partitions have never been "full" enough to invade the reserved space. The "worst" case was E: when it held three Images of C: occupying approximately 80%.

So, why do they fragment ...... ...... ?

If I´m getting too technical, please, let me know ...... ...... !

Thanks for Your time,
Christer

 

Hi Christer

You're getting very technical here - and you give us things to think about which we would not have thought of before!

This quotes from Diskeeper Pro Help may shed some light

"The Master File Table (MFT) is the area on an NTFS disk volume where the Windows NT, Windows 2000, Windows XP, and Windows Server 2003 operating systems keep all the information necessary for the operating system to retrieve files from the volume. The MFT also contains information such as the file creation, modification, and backup dates and times. In essence, the MFT contains everything Windows needs to know about the files on the volume. "

"MFT Record Count

This section of the Fragmentation pane or event log entry shows the number of individual file records found in the Master File Table (MFT). This figure will not necessarily correspond with the number of files presently on the volume, since the file records remain in the MFT, even after a file is deleted. "

"The MFT grows as the number of files on the volume increases, but is not reduced in size when files are deleted from the volume. "

As the MFT records everything Windows needs to know about the files on the volume it must be constantly writing to the MFT - hence it gets fragmented like any other file? I can't comment on the 12.5% figure you mention.

This may be of interest - I haven't read it closely!
http://support.microsoft.com/default.aspx?scid=kb;en-us;174619

 

Hi PeteC,
thanks for Your interest!

I have visited the DiskKeeper homepage but what they say doesn´t really answer my questions but I´ll have another look ...... I´ve missed the obvious before.

I´ve read the KB174619 too, that´s where I got the 12.5% from.

Another interesting site on the subject: NTFS.com

The reason for my "research" into this is that I had an error during an Integrity Test of a Norton Ghost Image. The "condensed" version of the error report:

Symantec Support wants me to get DiskKeeper to defragment the MFT but I don´t believe that´s the problem. My E: contains eight (8) large files, 300-700MB spans of Images and four (4) MFT fragments. It is currently used to 62% of its capacity.

I tend to believe that Ghost has a problem reading NTFS from DOS. All creating, checking and restoring of Images is done booted to DOS.
From within Windows, Ghost Explorer can load the Image and separate files can be extracted. The file which is being read when the error occurs during the Integrity Check can be read in Ghost Explorer and extracted to be opened by Acrobat.

This might be a single occurrence but if it isn´t, then I believe that reformating E: to FAT32 will solve the problem and not DiskKeeper.

My discussion with Symantec Support can be read here:

Christer's Ghost Problem

I know, booooooring ...... ...... ,
Christer

 

By the way, when I go Google on "IDE Controller Error 0x40" I get a lot of Linux Stuff ...... but nothing pertaining to my problem.

Google Search Results

Christer

 

Don't dismiss the Linux connection - I was reading this about Acronis the other day from another thread - it uses a Linux core for the boot disc - why not Ghost too?

http://www.pcnineoneone.com/reviews/sw/trueimage6.html

 

You´re right that dismissing things may result in missing the obvious ..... ...... like I´ve done on a few / numerous occasions.
When the Ghost Boot Disk wizard creates the GBDs, there´s a choise of PC-DOS (the IBM variant) or MS-DOS. I think that rules out the linux connection.

If anyone wants to get more technical ...... ...... :

System Performance and File Fragmentation in Windows NT

Inside NTFS

Christer

 

You are absolutely right - I had forgotten that