This weekend I noticed a behaviour of JkDefrag which, if a simple algorithm were added to JkDefrag could, in a few cases, result in substantial speed increases.
I was doing a defrag and in Phase 2, JkDefrag was moving parts of a large file up "above" the busy area of the SpaceHogs. This was an external volume and above the spacehogs everything was clear (no files, nothing unmovable, clear and free space).
I stopped the defrag before it finished, and restarted it. JkDefrag instantly zoomed in on the same "large file" it was working on before I stopped it. Then it did something I did not expect.
Instead of "continuing" to defrag the file from where it left off (i.e.: Appending the rest of the data that was still fragmented), it started moving the whole file again up above the part it had already completed.
A simple example, the nubmers are the block numbers of the file, x's are other intermediate files, s will be free space:
After stopping JKDefrag, it looked like this:
7xxx8xx9xxx0123456ssssssssss
When restarting JkDefrag, it did this:
7xxx8xx9xxxsss3456012sssssss
Then
7xxx8xx9xxxsssssss0123456sss
And finally
sxxxsxxsxxxsssssss0123456789
A simple thought to possibly gain more speed in certain cases: Check to see if "Free Space" after the current end of a fragment is large enough for the other fragments to fit into, and if so, continue filling from that point instead of re-moving the whole file.
Of course, the idea is easy, but maybe something with the Windows API prevents it
