Read/parse ATTRIBUTE_LIST attributes from the MFT

[Michael Bisbjerg]

Hi there,

 

I've noticed that Defraggler won't defrag some files despite them being fragmented. Through investigation, I found that Defraggler reads the MFT of the drive first and then begins defragmenting which leads me to believe that you're manually parsing the MFT (which is fine - and fast).

 

However, the files that remain fragmented tend to be the ones where the DATA attribute of the file is in an attribute list (and thus exists in another MFT entry) - it doesn't seem like Defraggler is parsing this correctly.

 

I suggest (given my assumptions are correct) that Defraggler be extended so that it can parse these attributes and better detect when files are fragmented.

 

Regards,

Mike

[Michael Bisbjerg]

Through more research, I've narrowed the situation down.

I found that Defraggler does indeed parse the ATTRIBUTE_LIST attribute, and some of its items - as I found a file which is fragmented (fragments stored in another MFT record) which defraggler also picks up as fragmented.

 

However, another file I have has ca. 2548 fragments - all in each their own MFT record (don't ask me why).

Defraggler shows this file as having 7 fragments.

 

I'll be looking more into it.

[Michael Bisbjerg]

Ok - you may ignore this request.

It turns out that NTFS doesn't always compact the fragmentation list.

 

So my file (which iirc has been defragmented by defraggler before) has ca. 2548 fragments. Of these, ca. 2540 are continous - meaning that one fragment ends where the next continue (they should have been written as one).

The 7 or so that don't do this, represent actual splits in the file - which defraggler has detected.

[Augeas]

With that many fragments - or more accurately cluster run allocations - the $Attribute_List attribute will itself be external, and contain only one datarun. This will point to a cluster or clusters which hold a list of all the attributes of the file. The list will contain the attribute type and the MFT relative record number. All your MFT extension records are listed in this cluster.

 

The cluster isn't part of the MFT but is allocated to the file, I think it's the last cluster in the file data allocation. Perhaps this is why Defraggler can't, or won't, touch it.

 

If you copy the file off your drive, rename it (for safety), and then copy it back again it should be in far fewer segments. Then delete the old file. Although the multi-fragmented file may have contiguous data, there will be many logical I/Os issued to read it, so fewer is better.

 

It's worth mentioning that defraggers defrag the MFT, not the disk. Moving the data is sort of secondary to the job.