Summary: the problem of a seemingly halted defragmentation process may be solved by turning off the option 'Move large files to end of drive...', regardless of the System Restore settings.
Hello, I too experience a very slow defragmentation process. Fortunately, thanks to the remarks of Danno, I was able to solve my problem by turning off the option to move large files to the end of the drive. I did not have to turn off System Restore to solve my problem.
In detail, this is what I experienced: I defragmented a 180 GB sized, 92 GB used, single-partitioned, 57% fragmented NTFS disk. At first, it seemed to be doing nothing, but it turned out to be calculating something. After a minute or so, it rapidly completed the first 2% of the process, after which it almost came to a full halt. It still used 100% of one CPU-core, so it was still busy, and once every so many minutes, the filename from the current status changed. After an hour or two and reading this topic, I lost my confidence in the process; aborted it; unchecked the 'Move large files to end of drive' option; restarted the defragmentation; and voila, now it was actually busy with swapping files instead of computing some seemingly computational hard problem.
Having a background in theoretical computer science, I'm quite interested in the calculations involved to move large files to the end of the drive. Which mathematical problems need to be solved during the process, and which algorithms are used? Judging by the time it takes, it seems almost (but I may very well be wrong on this one) that it is trying to solve an NP-hard problem, or otherwise uses a backtracking algorithm to solve some problem --- for each file it needs to process.
edit: I also wondered, if the widely known but mostly forgotten fact that System Restore points are compressed by Windows may have anything to do with it. Maybe the strange consequence that the 'Size on disk' may actually be smaller than the 'Size' triggers some kind of bug?
