You would not gain much anyway.  In fact it would make things slower.

Perhaps you are right, but while we find some measuring data, we just have prejudiced opinions. There is people thinking that more time than suspected is lost in moving heads back and forth when defragmenting big files. I've had this sensation too, and also that dumping from one drive to another, and then back to the first one, is a much more painless operation, but it must be proved.

Someone should build the test, creating a big spacehog (a 800Mb video file for example), divide it in some hundreds of random fragments, defragment it in both ways, then compare times.

Move the whole content tothe 1TB drive and then back.
then the 30GB drive is defragmented.

I suppose you were joking, but I miss some  to be sure.

And in case not, how could you send spacehogs to the end of the partition, for example?

oops, I did the search... with the wrong keywords. Anyway I had fun thinking and writing about it (and reinventing the wheel too), so it did worth the pain.

Please consider deleting this thread to keep the forum clean of junk.

Thanks for your answer, and for not being rude!

Have you ever considered using another physical drive as temporal drive for big files defragmentation (or even not so big)?

The reason for this consideration comes when comparing both ways of moving files.

The usual way is dividing file into blocks and move each block in sequence to its final defragmented position, which requires as many average hard disk head movements as blocks. Average movements are slow, against sequential hard disk movements that are fast and more desireable, in case you can choose.

So, the another way proposed is first moving files to a 2nd physical drive, and then back to the original one.

I would like to spend some time analyzing both ways in terms of "average" head movements (slow ones), and "sequential" head movements (fast ones).

• - Deframenting inside the same hard disk:
  
  • 1) Disk head jumps from arbitrary position to the start of block to read. Jump distance = average
  • 2) Block reading. During this process, say disk head moves X times, usually 1 sequential head step each time, although depends on fragmentation.
  • 3) Disk head jumps to the start of block target position. Jump distance = average
  • 4) Block writing. During this process, disk head moves X times, 1 sequential head step each time. No fragmentation is considered in this phase.
  • 5) (loop to step 1 until whole file is moved)
  Total estimated head movements= (2*average + 2*X *sequential) * num_blocks_per_file
  

• - Defragmenting drive (named Drive1) using another drive (named Drive2) as temporal drive. It requires 2 steps, first writing the file to temporal drive, then from temporal drive back to original drive. Our goal is to avoid average head movements, since then are the slowest part of the hard disk activity, and substitute them with sequential disk head movements, much faster.
  
  
  
  
  
  • Step 1: File is written from Disk1 (file is fragmented when reading) to Disk2 (file is defragmented when writing)
    
    • 1) Disk1 head jumps to start of first read block position. Jump distance = average
    • 2) Disk2 head jumps to start of first write block position. Jump distance = average
    • 3) Block reading on Disk1. During this process, say Disk1 head moves X times, usually 1 sequential head step each time, although depends on fragmentation.
    • 4) Block writing on Disk2. During this process, disk head moves X times, 1 sequential head step each time. No fragmentation is considered in this phase.
    • 5) Locate next block read position on Disk1, usually 1 sequential head step ahead from actual head position.
    • 6) Locate next block write position on Disk2, usually 1 sequential head step ahead from actual head position.
    • 7) (loop to step 3 until whole file is moved)
    Partial estimated head movements in this Step 1 =
       2*average + (2*X *sequential+2*sequential) * num_blocks_per_file
    
  
  
  
  
  
  • Step 2: File is written back from Disk2 (file is defragmented when reading ) to Disk1 (file is defragmented when writing)
    
    • 1) Disk1 head jumps to start of first read block position. Jump distance = average
    • 2) Disk2 head jumps to start of first write block position. Jump distance = average
    • 3) Block reading on Disk2. During this process, disk head moves X times, 1 sequential head step each time. No fragmentation is considered in this phase.
    • 4) Block writing on Disk1. During this process, disk head moves X times, 1 sequential head step each time. No fragmentation is considered in this phase.
    • 5) Locate next block read position on Disk2, usually 1 sequential head step ahead from actual head position.
    • 6) Locate next block write position on Disk1, usually 1 sequential head step ahead from actual head position.
    • 7) (loop to step 3 until whole file is moved)
    
    Partial estimated head movements in this Step 2 =
       2*average + (2*X *sequential+2*sequential) * num_blocks_per_file
    
  
  
  
  
  

Whole total estimated head movements (Step 1 + Step 2)=
      4*average + (4*(X+1)*sequential) * num_blocks_per_file
[/li]
[/list]




Now we can discuss what do we prefer, if this accounting:
(2*average + 2*X *sequential) * num_blocks_per_file

or this one:
4*average + (4*(X+1)*sequential) * num_blocks_per_file


I think the second one is preferable, since slow head movements are now out of the parenthesis, and the hard job only handles sequential head steps which is the fastest mechanical operation that a hard disk can do. Note that "average" head movements means around 10ms each one, which is a very long time when talking about computers.

If a sequential movement is more than 4 times faster than 1 average movement (and it is by far!), this system could be useful.

Does it make sense?

[will inherit]

I defragged moving some .rar files and stuff like that to the end of disk, and often accesed files to the start of disk. There appeared a big gap between them (see 1st image attached).

Then, I copied a new file and Windows placed it... In the middle of the gap??!!  (see 2nd image)

I thought that part of the defragmentation strategy was not only keep files defragmented, but also keep gaps! Gaps are important, because they will be the files of the future. The more healthy (defragmented) the gaps are, the more defragmented will be the files when they get dropped into, because these will inherit the previous gap fragmentation!

Why does Windows enjoy fragmenting gaps when it would be soo easy to keep them as big as possible, by choosing their start or end areas to place new files? Is it the old Wintel paranoia again? (i.e.: Windows contributes making your computer slower, so you go and buy another one, so Intel earns money, and Microsoft too, and the cycle repeats again). Please let me know it isn't, and that this is part of a more complex algorythm that my mind will never grasp.

Thanks!