|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> wrote:
> Why does it take such a humongous amount of time? I can't understand.
As someone already said, head movements is the limiting factor here.
Once the defrag software has made up its mind where to ultimately place the
files, the remaining time it will spend...
- picking up clusters from their original position (remember, the files start
heavily fragmented, so *many* major head movements to be expected here already)
- copying those clusters to their target position (or, more frequently, an
interim position) far away (another major head movement; fortunately, we're
talking about contiguous clusters now)
- updating the File Allocation Tables (there's typically two of them) at the
start of the disk (one more major head mvoement), to reflect the changes
- doing roughly the same to move clusters from interim positions to their target
position (fortunately, they should be contiguous already by now).
The speed of a defrag software will heavily depend on how good it is at
minimizing head movement; for instance, if for some reason clusters of a file
happen to be ordered wrong way round (e.g. C...A...B...D), a naive defrag
software may try to pick them up in logical order, while an intelligent one
could recognize the situation and pick them up in physical order instead.
Similarly, a naive software may move clusters out of the way to the very end of
the disk - while an intelligent one may temporarily store some clusters even
where other clusters are intended to end up, and just make sure the spot is
free again soon enough.
Having lots of physical main memory installed should help, because a bigger
number of clusters can be processed at once, and at least head seeks for
writing the clusters back and updating the FAT will be reduced.
Having a disk with >50% free space helps a lot, too - otherwise clusters may
have to be moved back and forth multiple times before reaching their final
destination.
For some really hard cases, it may be worth considering to mirror the whole
disk, delete all the (movable) files from the original one (remember to empty
the recycle bin), then copy those files back from the mirror. If we're talking
about an OS partition, doing this on a different machine may work (in case it
doesn't, you can still do an exact restore from the mirror).
Placing applications, games and user data on a partition separate from the OS is
a very helpful thing, too.
> I also noticed that both defragmenters failed to use the free space
> in the partition (over 80 GB) to their advantage, and instead moving
> small clusters around one at a time. I'm pretty certain that if all the
> free available space was used to copy data, the whole process could be
> a lot faster.
Maybe the defrag software was actually able to move most clusters directly to
their intended destination, without having to temporarily store them somewhere
else. Or it chose temporary storage location the smart way, as close to the
source or intended destination as possible, to minimize head movements.
Post a reply to this message
|
![](/i/fill.gif) |