Isochroma

I have seen excuse after excuse from Piriform's developer(s) why they cannot or should not enable / code Defraggler to execute multiple simulataneous deframentations on separate drives. These excuses have included (not all on this thread): 1. Multithreading Defraggler would not result in a performance improvement since quote 'the bottleneck is the I/O (ie. physical drives): 1A. Answer for Single Drive with Multiple Selected Partitions: As other multidrive-capable defragmenters do, Defraggler could check the disk source of all the partitions selected by the user for defragmenting and then defragment them one-by-one-per drive but in parallel to other defragmentations on other drives. 2. Simultaneous defragmentation of multiple drives would not result in significant/any increase in performance due to Controller I/O Limitations: 2A: Answer for Single IDE Controller: All modern IDE controllers use Busmastering UDMA which provides 100 / 133 MB/s transfer rate per cable which is far faster than two physical hard drives [Master & Slave] can transfer data on that single cable with both drives at maximum linear sequential read speed - unless they are the now-rare IDE-SSDs - which since they are SSDs don't require defragmentation anyway. 2B: Answer for Multiple IDE Controllers: The only limitation on I/O in this case is the PCI/PCIe bus which is fully capable of carrying all data from parallel reads on multiple drives with tons of bandwidth to spare. 2C: Answer for a Single SATA Controller: Each SATA port is entirely separate with no cross-contention and provides 150/300/600 MB/s per port which is far more datarate than any mechanical drive can read at and faster than many SSDs's datarates. When the data gets to the controller chip it also travels in parallel paths or is merged into higher-clocked sequential lanes for transfer to PCI/PCIx/PCIe or via proprietary Southbridge-CPU links that many Intel boards now use. These links provide far more than enough datarate to handle parallel operations on multiple drives and indeed that is their exact purpose. 2D: Answer for Multiple SATA Controllers: Same answer as 2B. Bus Data Rates: PCI 32-bit x 33MHz: 133 MB/s (Common) PCI 32-bit x 66MHz: 266 MB/s (Uncommon) PCI 63-bit x 33MHz: 266 MB/s (Uncommon) PCI 64-bit x 66MHz: 533 MB/s (Uncommon) PCI-X: 1064MB/s (Uncommon) PCI-X 2.0-1: 2132MB/s (Uncommon) PCI-X 2.0-2: 4266MB/s (Uncommon) PCIe v.1: 250 MB/s PER SEPARATE LINK PCIe v.2: 500 MB/s PER SEPARATE LINK PCIe v.3: 985 MB/s PER SEPARATE LINK PCIe v.4: 1969 MB/s PER SEPARATE LINK Parallel simultaneous defragmentation of multiple drives equals a massive speed improvement that exceeds by as many times as drive-independent selected partitions the equivalent one-at-a-time speed. A velocity improvement that increases in linear proportion to the number of drive-independent partitions selected for defragmentation. I can offer an explanation why Defraggler's developer(s) have so far resisted the upgrade of this application to MSDD (Multiple Simultaneous Drive Defragmentation). It's due to Defraggler's legacy code which was written to defragment only one drive at a time. Despite all the versions issued since the first, that engine has never been fundamentally altered. Certainly bugs were removed in newer versions. Definitely new capabilities were added to allow the defragmentation of USB drives for example. However, even the newest version of this software still uses the same single engine under the hood. There is a way users can force Defraggler to defragment multiple drives simultaneously. Notice that if you try to run two copies of Defraggler in an attempt to do parallel defragmentation, the second copy of Defraggler pops a window with the text: "Defraggler is already running.". When Defraggler starts up it checks system memory space for another copy of itself and if it finds this copy it pops the dialog and clicking this dialog's OK button sends the second executable to self-termination. Duplicating the Defraggler.exe executable then renaming it doesn't stop the detection, thus Defraggler is checking the Process Name in memory, not the process's image file on-drive. Using Resource Hacker to change the renamed executable's string identifiers does not prevent the code from identifying a duplicate upon execution. Disassembly will allow a code-trace to find both the method at tree-breakpoint where the check is performed. Then the check can be disabled thus allowing multiple copies of Defraggler to run in memory simultaneously. This will be less work than further lobbying Defraggler's unresponsive developers to rewrite the obviously dated, shortsightedly single-engined code.

Parallel support is needed. I have a half-dozen disks in one box and four in another. It takes longer and longer to defrag drives sequentially, while the time to completion increases only minimally with parallel operation when the number of drives is increased. I'm already looking for another app that can do parallel defrag. PS. Don't forget develpers! When it's time to add this feature, MAKE SURE TO CHECK THAT MULTIPLE PARTITIONS ON THE SAME DRIVE CANNOT BE SIMULTANEOUSLY SELECTED IN THE GUI!. Otherwise one or more drives will be forced to do two or more move operations simultaneously, drastically decreasing performance and wearing out the drive. The command-line version will have to handle that situation a bit differently.

I've got some problems with the feature that moves files to the end of the drive. I'm using Windows XP SP2 and Defraggler 2.01.239 from the GUI. 1. Setting the minimum filesize to 0 MB should move all files to the end of the drive. Instead, none are moved - defragmentation proceeds as if the "Move large files to end of drive..." checkbox is unchecked. 2. Setting the minimum filesize to 1 MB should move all files => 1MB to the end of the drive. Instead, only a random selection of files is moved, then defragmentation stops. I want to be able to move all files to the end of the drive, leaving clean space at the beginning for fastest writes. I cannot do so with Defraggler as it currently behaves. The problem is that Defraggler does not follow the options provided in the GUI regarding file movement. A recoding is necessary. It seems that as soon as Defraggler becomes satisfied that the files are fully defragmented, it stops the process even if the rules regarding moving large files aren't fulfilled.