Back when I used to only use hard disks the way I'd be able to get files more contiguous and tightly packed on my secondary internal backup HDD was to use CCleaner's Wipe Free Space - it filling all the empty space makes it so that it will cause Windows to temporarily remove the MFT Reserved Zone that often gets into the way. Then following that immediately do a full defrag with whatever defrag software you wish to use that also has the ability to tightly pack the files (not all of them can do that however and many give up too quick). Then run ChkDsk /F on the drive so that it causes Windows to re-make the MFT Reserved Zone followed by a reboot.
- Move the files back to that one drive. Then Windows will place all those files in a nice contiguous row on that drive. And I assume that also includes the $MFT.
That won't work Willy. The $MFT is created - as are all the system files - at device format time, before any user files are loaded. The MFT is allocated in 'zones' of 200mb chunks, about 50,000 4k clusters, and all except the first zone can go anywhere on the device. The location of the start of the MFT is held in the volume boot record so I imagine moving it (safely) would be quite a problem. I would think that reading a very large file - even if it has been loaded contiguously - would hardly notice the few milliseconds taken to pass over the MFT.
What I read in your reply is that formatting a drive certainly would help to recreate/reset (whatever you want to call it) the MFT . Nothing in your reply contradicts/refutes my reply. The formatting process could very well also update/rewrite the Volume Boot Record.
Based on what have seen in Defraggler, formatting a drive does force Windows to re-create the MFT from scratch. And I have formatted a few drives in the past. Afterwards I ran Defraggler and the Defraggler drive map told me that the enitre drive was empty except for a few blocks at the beginning of the drive.
Although I am aware that Defraggler has every now & then a problems showing the place where the $MFT is located on a drive.
Perhaps someone is willing to see what happens with the MFT after a format ???
Formatting a partition creates both the Volume Boot Record and the MFT. If you format a device as NTFS and then quick scan the files with Recuva (check scan for non-deleted files) you will see about 25 live system files, the first being the $mft. The MFT holds the addresses of all the files, including itself, so it must exist before any user file can be allocated. Where it is positioned is due to the formatting process. And if the MFT is already created whatever is done with user files can't alter that.
Where files are on a storage device can't be established (easily) by looking at the drive. Defraggler (and any software) creates its drive map by looking at the MFT (where all the file names and cluster addresses are held) and by possibly looking at the cluster bitmap, where each cluster is flagged as being in use or free. Defraggler's drive map is an illusion.
- Just let Defraggler search for "$MFT" and - presto - it will find the $MFT. To be precise DF found 2 $MFT related files on my laptop. One was "$MFT" which was in 2 fragments (size: ~ 660 MB) and the other was "$MFTmir" (size: 4 kb) in the 1st block in DF on my C: drive. I assume that $MFTmir is the file that is written/created when the user formats a drive and contains information that points to one or more fragments of the $MFT itself. I think $MFTmir is even more "sensitive" than $MFT. If $MFTmir isn't there then the entire filing system "falls apart".
£MFTMirr is a one cluster file containing a copy of at least the first four records of the MFT (larger cluster sizes hold more records). It is a system file to enhance integrity and I would imagine that NTFS would fall over if it were not there. Offsets 0x30 and 0x38 in the Volume Boot Record hold the MFT and MFT Mirror logical cluster addresses. The first two records in the MFT point to the MFT itself and the MFT Mirror.