Defraggler Defrag Can Seriously Fragment $Mft

Defraggler Defraggler Bug Reporting
1

Have noticed $Mft seriously fragmented in old Vista 32 NTFS system filesystem via Drive Map. Have found in Win 7 64 that Defraggler Defrag has probably caused this fragmentation, as when $Mft is only fragmented file, it relocates the $Mft file into holes on apparently first fit basis. Though that does not explain the very high number for framents (1,600+ on 182MB file) as there tend to be only 5 or so holes to fill, mostly shared with 0 or 1 file, and only one has about 20 smallish non-fragmented files in it.

The tool Contig, can relocate the $Mft into 2 fragments, there's discussion in thread Defragging the MFT

So at present it's repeatable, and undoable.

2

Do you have to do anything special with Contig? Or will something like I use suffice:

contig -s -q "c:\*.*"

I notice the help file (contig -?) states it can defrag all types of those $Mft, etc., files but it doesn't state if something like this has to be done:

contig "c:\$Mft"

Edit:

Also allot of third-party defrag tools freeware and paid fragment the MFT, some worse than others.

3

I run the command shell "as administrator". Then run contig something like "Contig -v V:\$Mft".

That defragged both $Mft and $Mft::Bitmap. I couldn't copy & paste the text output directly as presumably MS don't consider text command support important enough to implement it.

4

Hi,

During the defragmentation Defraggler treats $MFT similarly to normal files but with one exception - it tries to lay it immediately after the first $MFT cluster. This is caused by the fact that the first cluster of $MFT is unmovable.

If Defraggler had increased the number of $MFT fragments during the defrag significantly, please create a debug log from such defrag (http://www.piriform.com/docs/defraggler/troubleshooting/running-defraggler-in-debug-mode) so we can analyze it and solve the issue.

Best regards

Romanoff

5

If Defraggler had increased the number of $MFT fragments during the defrag significantly, please create a debug log from such defrag (http://www.piriform.com/docs/defraggler/troubleshooting/running-defraggler-in-debug-mode) so we can analyze it and solve the issue.

Thanks for the explanation, I should say this is significant : MFT increased from 2 to 1700 fragments according to Defraggler, Contig counts $Mft and $Mft::Bitmap as different files.

Microsoft Windows [Version 6.1.7600]

Copyright © 2009 Microsoft Corporation. All rights reserved.

T:\Win\Contig>Contig

Contig v1.6 - Makes files contiguous

Copyright © 1998-2010 Mark Russinovich

Sysinternals - www.sysinternals.com

Contig is a utility that defragments a specified file or files.

Use it to optimize execution of your frequently used files.

Usage:

Contig [-a] [-s] [-q] [-v] [existing file]

or Contig [-f] [-q] [-v] [drive:]

or Contig [-v] -n [new file] [new file length]

-a: Analyze fragmentation

-f: Analyze free space fragmentation

-q: Quiet mode

-s: Recurse subdirectories

-v: Verbose

Contig can also analyze and defragment the following NTFS metadata files:

$Mft

$LogFile

$Volume

$AttrDef

$Bitmap

$Boot

$BadClus

$Secure

$UpCase

$Extend

T:\Win\Contig>Contig -v V:\$Mft

Contig v1.6 - Makes files contiguous

Copyright © 1998-2010 Mark Russinovich

Sysinternals - www.sysinternals.com

------------------------

Processing V:\$Mft:

Scanning file...

V:\$Mft is already in 1 fragment.

------------------------

Processing V:\$Mft::$BITMAP:

Scanning file...

V:\$Mft::$BITMAP is already in 1 fragment.

------------------------

Summary:

Number of files processed : 2

Number of files defragmented: 0

All files were either already defragmented or unable to be defragmented.

// Run Defraggler Defrag on V:

T:\Win\Contig>Contig -v V:\$Mft

Contig v1.6 - Makes files contiguous

Copyright © 1998-2010 Mark Russinovich

Sysinternals - www.sysinternals.com

------------------------

Processing V:\$Mft:

Scanning file...

Scanning disk...

File is 45679 physical clusters in length.

File is in 1699 fragments.

Moving 45679 clusters at file offset cluster 4 to disk cluster 13894015

File size: 187105280 bytes

Fragments before: 1699

Fragments after : 1

------------------------

Processing V:\$Mft::$BITMAP:

Scanning file...

V:\$Mft::$BITMAP is already in 1 fragment.

------------------------

Summary:

Number of files processed : 2

Number of files defragmented: 1

Average fragmentation before: 850 frags/file

Average fragmentation after : 1 frags/file

T:\Win\Contig>

Debug log attached : Defraggler64.exe.2_2_2532011-02-17_12-07.txt

6

Still present with 2.03.282

According to the Contig tool the $MFT is in 1 piece and moved (may be it is fibbing and discounting first cluster of $MFT), but at least it allocates the rest in 1 piece though I'd prefer nearer the main file blocks and $Bitmap next to it.

You could use Recuva (as above) to see the MFT cluster allocation

I've installed and tried to use Recuva, but it just seems to want to look for deleted files. If it can report on $MFT cluster allocation, it is not obvious enough how to do it to me even after looking through the program feature documentation. Could you explain how, please?

If I know what clusters are free, I think Contig can defrag to a specific location, if manually set on command line, but I've no safe way to know where to try to relocate it at moment, so allow it to automatically decide.

7

Open Recuva and cancel the Wizard, or switch to Advanced Mode (I always use Advanced Mode, it makes me think that I am in some small way advanced). Right click on the l/h panel and select List View in View Mode. In Options/Actions check Scan for non-deleted files. Run a scan. Chop stage 2, or even stage 1 if you have a lot of files. $MFT will be the first file in the list. Highlight $MFT then click on the Info tab on the left. This will show the cluster allocation of the MFT in decimal offsets, which is hugely easier than converting little-endian hexadecimal cumulative run lists from the $MFT MFT record.

This shows the cluster allocation for the file $MFT, not the cluster allocation for the disk, which judging by your last sentence might be what you are looking for. Using Recuva is just an easy way to see how many fragments a file has.

Oh yes, the MFT will always show at least two allocated fragments. There are two attributes in the $MFT record in the MFT that allocate clusters, $Data and $Bitmap. The $Data attribute defines the clusters of the MFT and the $Bitmap attribute defines the cluster (usually one) of the MFT bitmap. This is not the disk cluster bitmap. In my case the MFT bitmap cluster immediately precedes the MFT on the disk.

8

Ah OK, sneeky I missed the 'not deleted' file option.

Filename: $MFT

Path: V:\

Size: 178 MB (187,105,280)

State: Not deleted

Creation time: 19/10/2007 23:20

Last modification time: 19/10/2007 23:20

Last access time: 19/10/2007 23:20

Comment: No overwritten clusters detected.

4 cluster(s) allocated at offset 786432

1 cluster(s) allocated at offset 1233057

1 cluster(s) allocated at offset 1224516

6 cluster(s) allocated at offset 4458165

The last Contig run to fix V:\$MFT, I didn't save the actual output, it was similar to the previous :

Processing V:\$Mft:

Scanning file...

Scanning disk...

File is 45679 physical clusters in length.

File is in 1699 fragments.

Moving 45679 clusters at file offset cluster 4 to disk cluster 13894015

Moving 45679 clusters at file offset cluster 4 to disk cluster 13894015

My thinking was I could engineer a free spot for the cluster allocation, by either making a file and deleting that occupied roughtly the right place, or when it's tidy, subtract a good number of clusters from the $Bitmap allocation found or something. See those files are in goodly free space, after the full Defrag runs; I had a good clean up of this partition V:\

If the 4 cluster(s) allocated at offset 786432 is $MFT and 1 cluster(s) allocated at offset 1233057 is $Bitmap as shown by Defraggler drive map, then the numbers seem plausible. Shame I didn't log my last Contig run, it seems to fit romanov's explanation anyway.

It's confusing if Contig is lying somewhat in it's output, and then you see $MFT & $MFT::Bitmap being 1 fragment each, and then Defraggler seeing 2 frags for a supposedly defragged file.

Suffice to say, I probably am best ditching V: and re-initialising the FS beore re-using. Though it's a real weakness in the $MFT allocation doing full Defrag, if this happens after plenty of effort to free up space, and defrag files and free list.

9

Are we missing a few digits in the Recuva report? There's only 12 clusters defined. You should have around 44-45,000 clusters for 178 mb.

Curiously, considering I'm on XP and my disk is highly likely different from yours, my much smaller MFT starts at the same cluster number (with the MFT bitmap positioned at one cluster prior to that).

Size: 29.5 MB (31,014,912)

7572 cluster(s) allocated at offset 786432

1 cluster(s) allocated at offset 786431

I know nowt about Contig.

PS 786432 in hex is 0xC0000. That's a nice round number.

10

Thank you for the explanation and helpful interest by the way :D

So for interest, I'll republish for both Win7 & Vista System disk for comparison purposes.

Never ran Contig, on the Win7 system partition as I haven't had any anomaly with the $MFT which seemed to need fixing.

The 0xC0000 offset must be what romanov meant by "first cluster" of $MFT, so Defragglers Full Defrag layout policy sounds like it's seriously compromised, if it is filling in very many small holes, at the beginning of the Full Defrag (as it appears to be doing).

Win7 64 bit upgrade - fresh NTFS made during installation

Filename: $MFT
Path: C:\

Size: 150 MB (157,286,400)


State: Not deleted


Creation time: 06/11/2009 01:05


Last modification time: 06/11/2009 01:05


Last access time: 06/11/2009 01:05


Comment: No overwritten clusters detected.


38400 cluster(s) allocated at offset 786432

6 cluster(s) allocated at offset 4085789

Vista 32bit

Filename: $MFT
Path: V:\

Size: 178 MB (187,105,280)


State: Not deleted


Creation time: 19/10/2007 23:20


Last modification time: 19/10/2007 23:20


Last access time: 19/10/2007 23:20


Comment: No overwritten clusters detected.


4 cluster(s) allocated at offset 786432

1 cluster(s) allocated at offset 1233057

1 cluster(s) allocated at offset 1224516

6 cluster(s) allocated at offset 4458165

Although the Win7 is on a later slower part of disk, the scan was noticeably fast compared to that of V:

I have of course tried multiple passes of full defrag & freespace defrag & run of Contig to hope to get a reasonable $MFT that Defraggler likes, rather than relocating it on every Full Defrag run.

11

There's still something up with the V spec, 12 clusters just isn't enough.