Incorrect MFT fragmentation

[penguin2]

I noticed JKdefrag says my MFT is in 1 extent while the windows defrager says its in 2 extents which one should i go with? I do know that a MFT in 2 extents wont affect performance.

[jeroen]

Can you give me more information? Where and how exactly did you see the extends in JkDefrag and in Windows? JkDefrag normally reports fragments, not extents. A fragment is a solid block on disk consisting of 1 or more extents, all following each other, joined up without space in between. Most defragmenters calculate fragments like this. Only in debug mode "-d 4" or higher will the "jkdefrag.log" file show the extends.

[penguin2]

Sry

Im used to linux when analyzing fragmentation and it always shows extents. but i am done with linux.

Jkdefrag and xp defrag both report fragments. But why does Jkdefrag show that the MFT is in 1 fragment where the xp one shows 2 fragments?

[penguin2]

http://i307.photobucket.com/albums/nn299/articpenguin/Windozexp.jpg           <-------- xp defragmenter

http://i307.photobucket.com/albums/nn299/articpenguin/jkde.jpg <------------------------- jkdefragger



Oh i guess My MFT got fragmented again once i added 1.6Million files.

[penguin2]

regarding linux filesystems

I find ext3 and xfs are the most resistant. Ext3s block allocator places files in the same block group and xfs uses delayed allocation so when its time to flush the buffers the xfs block allocator will know the file size ahead of time.

JFS fragments the most

Dont care about reiserfs.

[jeroen]

Windows must be reporting the number of extends for the MFT, whereas JkDefrag reports the number of fragments. I am pretty sure that the Windows defragmenter does not show regular files as fragmented if there are contiguous extends, so there's a little inconsistency there in the Windows defragmenter.

[penguin2]

My bad they both show fragments and i did research maybe why jkdefrag reports one less fragment than windows


NTFS stores a redunant copy of the first 16 records of the MFT and reports that as a fragment.

Jkdefrag probably dosent report that reduant copy and shows 1 fragments.

[jeroen]

NTFS stores a redunant copy of the first 16 records of the MFT and reports that as a fragment.

Ah, I see. Yes, that explains it. JkDefrag reports that as a separate file, the "$MFTMirr" file. The NTFS specification says it's a separate file, it has it's own filename, everything else about it is normal (except that it is a special system file). So it's a little bit strange that Windows counts it as a fragment of the MFT, when in fact it is not. That way Windows will always report at least 2 fragments for the MFT, even when it is fully defragmented. Pffff, Microsoft.....

[boco]

AFAIK the first 16 records must be always at the start of the disk, they can't be moved (the records for the $-files including the $MFT itself). The rest of the $MFT can be everywhere on disk. So unless the whole $MFT is at the start of the disk it's always at least 2 fragments. JKDefrag reports that, it treats $MFT as a file, as it is one. But I guess Windows itself does not report that, as to avoid questions like 'Why I can't fully defragment the $MFT?'. These split 16 records don't are a problem anyway, as they store the attributes of the most used files on the drive and are heavily cached anyway.

I don't have a single drive where the $MFT is <2 fragments (Diskeeper shows the correct fragments (2) for me). So I'd say 2 fragments counts as defragmented in case of $MFT. Maybe JKDefrag should reflect that (showing $MFT with 2 fragments green).

But it works great anyway! Looking forward to the big 4.

[jeroen]

AFAIK the first 16 records must be always at the start of the disk, they can't be moved

Only the bootblock is always at the beginning of the disk. The bootblock is the first 512 bytes of the disk, and amongst other things contains the location of the MFT. The bootblock is not part of the MFT and does not have a filename. So, the first 16 inodes in the MFT do not have to be at the start of the disk, they can be anywhere.

The Microsoft defragmentation API on Vista can move everything of the MFT except for the first 16 inodes (usually 16 kilobyte). I don't know why. You would say that it should be possible to move the entire MFT, especially on a disk that is not mounted, but perhaps it is a limitation of the NTFS filesystem drivers. JkDefrag version 4 will be able to move the entire the MFT, except for the part that contains the first 16 inodes. This will become a fragment.

Maybe JKDefrag should reflect that (showing $MFT with 2 fragments green).

Yes. Version 4 of JkDefrag will completely ignore that first unmovable block of the MFT, and will only count and show fragments after that.