Halliday

Ah. that is true if one chooses to set SD to only defrag files with greater than some percentage of fragmentation. I, on the other hand, have always chosen the "Always Defrag" option. If this option also skips files with fragmentation below some percent, then it is not doing what it says! (Besides, I have taken the analysis report, calculated the fragmentation percentage, and compared to the after defrag report: Files with lower percentage of fragmentation were defragged, even when files with higher percentages were stated as "No defrag needed".)

Yes, Mel. I know that a drive can never be set up "perfectly", especially not for the long term. (Of course, if Windows were not so "stupid" in its use of the disk, there would be far less need for defragmentation. My UNIX systems never needed defragmentation, even running 24/7, and often completely filling the disk, including running applications that expanded the swap file even to the point of swapping-itself-to-death.) I was simply using the "drive is 'perfectly' set up" as a shorthand for attaining no further progress because there is no further fragmentation to be removed, nor optimization/prioritization to be gained, not due to lack of space for such work, nor issues with unmovable files, etc., but because everything is the best possible, for the time being. Basically, if no further progress can be made due to lack of free space, and/or unmovable files, I want SD to "fess up" to this issue, rather than the usual "No defrag needed", even when defragmentation is clearly "needed".* (Of course, one could suppose that an even smarter defragmentation program would be able to attain usage information such as to be able to predict, to at least some degree, how much buffer space certain heavily used, and expanded files may need for near term future expansion.) My system with my largest disk (a terabyte) performs just fine, even though my drive Map for my large disk is full of red, is reported as having nearly a 60% fragmentation rate, and shows almost no "Free Space", even though I have 202.6 GB free out of 931.5 GB, according to SD, right now. My wife's laptop, on the other hand, with a half-terabyte drive, has been suffering from "WinRot" for the past year. It's performance has degraded to the point that it is downright painful to use! I have been using the IObit tools for the last several months to try and help bring it back to usability, but have seen no noticeable improvement. (I will be backing it up to a 3TB drive, wiping, and reinitializing it soon. Such seems to be the way with Windows, it seems.) Anyway, just my two cents. David * I have a 189.8 GB file with 1,296,114 fragments, and a 34.2 GB file with 810,054 fragments that SD reports as "No defrag needed". The reality is almost certainly something else entirely, like a claim of "No Space to Defrag" (though, barring constraints due to unmovable files, even this can be worked around given sufficient time and good algorithms---at the very least, the fragmentation can be significantly reduced).

I vote A, since it encroaches the least upon the disk Map. I think the disk Map is too small, with too much other wasted space, and doesn't provide sufficiently fine granularity for today's large disks as it is!

After seeing instances where Defrag and Full Optimization made good, but quite incomplete progress on a drive, I would like to suggest the ability to run multiple Degrag passes: Allow the user to set the maximum number of masses, and run the defrag (especially with Optimize through Prioritize) until either the number of passes is complete, or until no further progress can be made. If no further progress can be made, please inform the user as to why. (The best reason of all, of course, is that the drive is "perfectly" set up. ;) )

This was to reiterate Dekker's suggestion: David

I must most strongly endorse the recommendation that SD v4 should "consolidate" free space. This is also referred to as "defragmenting" free space. Just as defragmenting files has benefits on performance for file reads (and modifications, so long as the length of the file need not be extended, at least), defragmenting free space benefits performance of writing new files, and has the benefit of, at least potentially, decreasing fragmentation of new files. This is a feature I remember having available, even in free disk defragmentation programs, decades ago! SD needs to provide better feedback on why it does not defragment files. We know that defragmentation of a file may be "skipped" because its percentage of fragmentation is below the user's chosen threshold (though, personally, I always choose "Always Defrag" for the "Defragment when fragmentation exceed:" choice), or because the file is larger than some user chosen threshold (though, again personally, I always deselect the "Skip files larger than ..." option: Even 10.00 GB is far too small a threshold for me!). We also know that there may be reasons why a file that would otherwise be selected for defragmentation may not be able to be defragmented: The file may not be moveable (such as when in use), of there may not be enough free space (or, more particularly, not enough contiguous free space) to allow for a complete defragmentation of the file. Please, please, please inform the user as to why defragmentation was not done on any particular file! "No defrag needed" is certainly insufficient, especially when I have files with over a million (yes, nearly 1.3 million) fragments! I, too, have been perturbed at SD's inability to properly sort its Report tab by file size. My suspicion is that the sort is a pure textual sort that doesn't recognize the size multipliers. It sure would be great if SD v4 could properly sort by file size. I also endorse improvements in the drive/file map on the "State" tab: I would like to be able to choose to have much smaller blocks for the drive/file map---all the way down to a single pixel, with no border, would be great. I endorse providing the user with how much space each block represents, approximately. I believe that some of the user concerns about files seeming to appear/disappear at "random" in the drive/file map could be helped if the colors of the blocks were not simply overridden by the type of the latest file found within a given block, but if the color were an "amalgamation" representing the percentage of the block of space taken by different file types. (Of course, this will only work as the number of different file types are small, and the colors are well chosen for this "blending" operation. I believe the most that could be properly accommodated is six file types, with colors of red, green, blue, cyan, magenta, and yellow, and black for free space/no file. Admittedly, one would certainly still have combinations that will be indistinguishable, but the present one-color-for-the-latest approach has far greater levels of indistinguishability!) It would be helpful if the user could decrease the screen real-estate taken by so much "blank/empty space" in the user interface (UI). My SD v3 has enough blank/empty space in the volume list, at the top, for at least two more drives (in addition to the two I do have). I don't need that much space being taken up for nothing! There is also too much space taken up under the control buttons/pull-downs: This control button/pull-down section could usefully overlap with the space to the right of the colored "Map:" blocks (and to the left of the "Shut down after defragmentation" check-box), at least when the window is wide enough (as in my case). It would be nice to have it "re-flow" when the window is resized. Anyway, I think that's enough for now. David