Intro Download and install Frequently Asked Questions Tips and tricks

Homepage







© J.C. Kessels 2009
MyDefrag Forum
May 25, 2013, 10:19:29 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Using other disk as temporal for defragmentation  (Read 838 times)
bob es ponja
JkDefrag Junior
**
Posts: 5


View Profile
« on: April 11, 2012, 12:21:31 pm »

    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?
« Last Edit: April 11, 2012, 04:08:20 pm by bob es ponja » Logged
jonib
JkDefrag Hero
*****
Posts: 810


View Profile
« Reply #1 on: April 11, 2012, 02:16:26 pm »

I don't want to be rude but was it so hard to take a quick look in the forum you're posting this too? if you had you would have found this use second drive to speed up defragmenting and reading that you would have found this Speed up defrag using multiple drives.

Would have saved you from writing this long post for nothing.  Wink

jonib
Logged

bob es ponja
JkDefrag Junior
**
Posts: 5


View Profile
« Reply #2 on: April 11, 2012, 03:48:55 pm »

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!
Logged
BloodySword
JkDefrag Hero
*****
Posts: 1113



View Profile
« Reply #3 on: April 30, 2012, 10:26:23 am »

It would be much easier if the Windows API would read up to 1GB of data into the RAM and then writes it down. But no, the API seems to copy cluster by cluster... So this makes it slow.
Logged

Greetings from Germany!
Keatah
JkDefrag Junior
**
Posts: 5


View Profile
« Reply #4 on: May 29, 2012, 01:52:28 pm »

Using a caching program like superspeed allows just that to happen. The head movement is literally cut in half!
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!