use second drive to speed up defragmenting

[orange47]

I have several hdds, and would like an option to use free space on other drives to speed up defragmenting. it should be safe enough so the files can be restored in case of interruption.

[Darlis]

Such a feature has been proposed before, see this thread.

[orange47]

that's the reason more to implement such feature. I presumed some would worry about safety. so it should be optional ('experts' only), and usable only on 'unmounted', data partitions. not C: or such..

[lh]

The windows API that this program uses does not work that way.  It takes a list of clusters (part of the file) and says move it from this part of the disk to this part.  It does not have the ability to move it between disks.

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

Lets say it takes 10 seconds to read a file from front to end (on both of your drives), and 10 seconds to write the same sized file (on both of your drives).

So it would take 10 seconds to read the whole file.  Then 10 seconds to write it to the second disk.

You then have to re-read the file from the second disk (another 10 seconds).  Then write it to the original disk in the new place (another 10 seconds).

If you use the copy to another drive method instead of windows API they are using now it would take 40 seconds.  You could overlap it some but you would at best end up with 25-30 seconds.

If you use the windows API they are using where it does all the work on the same drive it would take 20 seconds.  As you do not need the seconds set of read/writes.

[bob es ponja]

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.

[lh]

You are correct my math does not take into account seek time.  In order for it to be faster the total seek time would need to be slower than the total time for the entire extra copy you will be making.  I picked 10 seconds in my example to exaggerate the copying.  There would be a point where the two numbers would cross.  *HOWEVER*, the windows API call this program uses does not work that way.  He is using that function so he does not have to recreate all of the permissions and ntfs meta data that is associated with the file.  Which copying it to a second drive would cost.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364577%28v=vs.85%29.aspx

Large files are usually done fairly quickly I have noticed.  It is lots of small files where this api is slow.  That is due to the serial nature of the program and the overhead with 1 file.  As it happens more often with smaller files than larger files.  The program in this case could use overlapped operations to improve the speed.  However, that would make deciding where a file ends up much more complex (and would in some cases fail).

[Keatah]

I use a disk cache. This cuts down the amount of head movements in at least half. I visually confirmed it by running it on a drive that has a clear cover. You get a good solid 40% improvement in speed measured with a timer.

The cache program I use is supercache from superspeed, for example. And the major thing you'll notice right away is the heads become quiet with reduced chatter.