Minimum file size for moving large files to end of drive

[Sozz]

Hi all,

 

This isnt a big thing, but I'm just wondering whether this is a bug or case of "no one would ever want to do that" : when in Options >>> Defrag, if 'move large files to end of drive' is enabled, and "Movement settings" is set to 1MB or more, the defrag is done, and i see most 1MB files or larger are moved to the end.

 

If this is set to 0MB (which the settings accepts as valid), it seems to be ignored and says the defrag doesn't move anything to the end of the disk (according to the diskmap). The idea being if the value is 0MB, then i thought the program would interpret all files as 'large files'.

 

Basically, I want to move all files to the end of the disk temporarily. The program MyDefrag has a script which does this, but it takes a long time. At the moment, I have used Defraggler to move all files >1MB, and then Mydefrag to complete the process. Would be cool do have defraggler do this in one hit if the 0MB value were valid.

 

 

Cheers!

[Winapp2.ini]

Interesting idea, but I am curious as to why you'd want to do this.

[Sozz]

Basically I had a drive which was defragged with some utility in the past. The fragmented pagefile was towards the end of the drive (not the fault of a defrag utility per se, rather a system managed one, and XP decided to increase the size and place it at the end of the drive), and so was the MFT. Looked like the MFT reserved zone got trashed at some point, so it too was also toward the end of the drive and was very small. I realise this reserved figure can dynamically change, but on 'standard' installs that haven't been touched with third party defragmenters, I've always seen the reserved MFT at the beginning of the disk with a 12%~ allocation so the MFT can grow contiguously.

 

You know when you freshly format an NTFS volume and you get a blank bit at the start (fastest part of the disk) then pagefile, then MFT, and the MFT reserved zone, then finally the remaining free space? The idea being, windows has the pagefile/mft/reserved mft zone at the beginning of the disk (http://technet.microsoft.com/en-us/library/cc767961.aspx). My goal was to restore this disk to this conventional setup, without having to offload data from the partition (as there's *a lot*).

 

It's all finished now, but in the course of using this handy feature of Defraggler, I figured i might find out if 0MB is the equivalent of being disabled.

 

(FWIW, the combination of Defraggler to move large files first and then MyDefrag with its script to remove the remaining 'catch all' ~1MB files was much faster than letting the latter do the entire lot)

 

Cheers

[Winapp2.ini]

Hm, well the devs read all of the threads, so perhaps you'll see this feature enabled in a later version (or perhaps not, I don't know! )

[Rob Defraggle]

Very likely a non-zero "large file size" threshold is turning on the feature, and the default is zero which turns it off; re-using a value in this way to mean 2 slightly different things is quite common.

 

You know when you freshly format an NTFS volume and you get a blank bit at the start (fastest part of the disk) then pagefile, then MFT, and the MFT reserved zone, then finally the remaining free space? The idea being, windows has the pagefile/mft/reserved mft zone at the beginning of the disk

With Windows 7 and as far as I can see in Vista, it isn't done that way anymore.

 

A pagefile when used heavily, is likely to need fast Random Access, rather than maximum sustained sequential read/write speeds, similarly the $Mft. Rather than locating the pagefile on fastest part of disk, they seem to go around the centre of freespace, after most system & user files, until they fill the disk with rubbish from youtube & itunes.

 

If you can it's probably faster to do a full backup to another disk and remake & restore the NTFS volume fresh, rather than move files on same disk twice.