Diskeeper is aware of these very valid concerns, and handles them intelligently.

By design, Diskeeper doesn't defragment "within seconds of fragmentation occurring". It knows enough to wait an appropriate amount of time. That wait state can vary (minutes to hours), and is also dependent on available resources. Defragmentation of files is top priority, followed shortly thereafter by free space consolidation, and then directory consolidation and I-FAAST sequencing.

Another valid concern is generation of heat from an active CPU(s) and hard drive and the power consumption to operate and cool those components. The key here is that Diskeeper is only handling issues that, left unhandled, will result in even greater effort for those components when they are really needed. An ounce of prevention... (you know the rest).

When you first install Diskeeper 2007 it may well chug away at your file systems, even if you recently defragmented with Diskeeper 10. What Diskeeper is doing is applying some of the new performance technologies (such as directory consolidation), that were not performed in v10. It's typical to see your CPU (and the Idle Resources graph on the Dashboard) be busy around 40% or so. You'll find that after a short while, after Diskeeper has optimized your computer, that the resources drop off to 1% or less, with only the occasional spike as it learns of, and fixes recently "acquired" file system degradation.

One of the urban myths about defragmentation is that it could wear out your hard drive. That of course, is the exact opposite of what actually occurs. In addition to improved performance, regularly defragmented drives live longer than drives that are not defragmented. That is because the amount of work they have to do is reduced. Defragmenting a file in 100 pieces requires 100 disk I/O actions one time and then only 1 disk I/O every time that file is accessed - until the end of time itself or you delete the file (whichever is sooner).

Let's do some math. We'll take a file that is in 100 extents (fragments) that we will access 100 times over the next few years.

Case #1: Defragmentation (total disk I/Os required):

100 I/Os (to defragment)
+ 1 I/O * 100 (for each future access of the file)
----------------------
= 200 total disk I/Os

Case #2: No Defragmentation:

0 I/Os (to defragment - which we are NOT doing)
+ 100 I/Os (to access all the fragments) * 100 (for each future access of the file)
----------------------
= 10,000 total disk I/Os - aye caramba!

Note that the above is a simplification of the I/O activity to defragment or access a file - but it is a workable example. One thing Diskeeper continues to pioneer is the amount of total I/O generated to defragment a file. It generates far less I/O overhead than other technologies.

If Diskeeper were to needlessly shuffle files around all day, every day, all the above discussions would be moot. Power would be over consumed, drives would wear out too quickly, etc... However, Diskeeper does only what is needed to improve the performance of your file system - and no more. That design principle has always been at the core of what Diskeeper is all about, and it holds true with RealTime defragmentation just as it did with multi-pass defragmentation. The new benefit is now there is no waiting for peak performance - it just happens!