Here is another vote (if we have any) to have SSDs locked out by default from being Defraggler candidates. As for an ability to override the lockout, sure - why not for testing purposes. I would like to propose a more radical approach to SSD care and feeding. The problem with SSDs slowing down over time is a real one. SSDs are new to most people and because they emulate traditional HDD drives, the casual user assumes they exhibit all the characteristics of the HDD. So the more diligent users want to defrag them, organize file placement and wipe vacant clusters. Wrong, wrong, wrong!
The owner of an SSD must learn immediately to discard the idea that it is a disk. Simply put, the SSD is a bank of special memory (typically NAND chips) lumped together with a very smart memory controller. The memory controller lives between two interfaces, one to chat to your computer bus (SATA) and the other to chat with the NAND chips. For technical reasons there may also be buffering memory on either or both sides of the memory controller - but I digress. To say that the memory controller just makes the NAND look like a HDD is a gross understatement of its capabilities.
We need to understand a bit about NAND memory to appreciate the capabilities and limitations of SSD technology. NAND is slow memory, but as implemented in SSDs it has advantages; there are no read heads to move to various cylinders and, there is no need to wait for the spinning platter to deliver data to the read head. Yes - in pure sequential reading some HDDs can best SSDs, but most OS generated activity is random and so SSDs lead the pack. A SSD reads any data placed anywhere at maximum speed. Without arm seek delay or rotational latency and with decent transfer speeds, their performance is blazing. Data scattered all over the logical (virtual) drive will be delivered to the computer as if it was a contiguous block. Traditional defragging and file placement become moot points. There is one tiny exception but I will address it later.
NAND memory does have weaknesses which adversely affect SSD performance. Technical design applies a few confines when writing to NAND memory. In a perfect NAND world the target storage location is empty (virginal) and can be written instantly. However, if the storage location has been used it is considered dirty and must be erased before being re-written and, this takes more time. The erase / re-write steps cause the NAND chips to heat up and, doing so over and over to the same location leads to chip failure. In fact NAND chipsets do have a limited number of write cycles that, although extremely large, can be reached. (Your mileage may vary.) This is where the memory controller earns its pay. It will spread the usage out over all available chips to prevent high concentration spots. This is called Wear Leveling and for typical users gives a SSD a projected life span exceeding most HDD drives. Just like the HDD, the controller keeps space reserved to do address re-assignment for failing NAND blocks.
When it comes to writing, the SSD memory controller will always strive for maximum performance by assigning an empty (virginal) location rather than re-writing a dirty location. Despite any attempt by your software to write (or re-write) a specific logical block address (LBA) or logical cluster address (LCA), the memory controller intervenes and translates it to a NAND friendly (meaning: random) location. That's right - all the defragging in the world makes no difference, the physical block address (PBA) will be made random by the memory controller. This makes no difference to apparent drive speed but improves NAND longevity. If you try to defrag a SSD the pretty graphic will show everything ordered. It's not - you are only looking at the computer's logical view of the virtual disk. Physically you probably trashed all the empty locations and the PBAs are still going to be randomly placed. Whoa - that goes against everything we have learned about HDDs ! (Right - remember, it's not a HDD.)
Now for an exception to the rules. The only useful defrag operation is Free Space Consolidation and should only be done occasionally. Each NAND PBA block represents a space many times the size, for example, of a NTFS 4096 bytes cluster. When a SSD is very dirty and has a very large number of fractionally used PBAs, the controller winds up shuffling data in the NAND buffers for no useful purpose. Putting the fractionally used areas into common blocks and releasing the remainder as free space is a small price to pay. Even the commercial product "PerfectDisk 11" only does Free Space Consolidation on a drive that it recognizes as a SSD. Some other popular products make wild claims they can't possibly do, given the technological involved. Caveat emptor !
If you haven't gone to sleep yet, you should be asking "What about all those virgin locations? They aren't unlimited!" Absolutely right - without some intervention the SSD becomes completely dirty and slows way down. No problem you say, "Just write huge files of binary zeroes and erase them; better still use a fine product like CCleaner to do a Wipe Free Space." Sorry that does not cut it - all you will do is dirty the entire SSD with binary zeroes (or Gutmann patterns) and have shortened the NAND life. Erased NAND contents are really empty; contents filled by binary zeroes are not empty.
With first generation SSD drives, you have to run manufacturer specific boot level programs to cleanup the dirty blocks. This is a pain because you have to backup everything, clean the whole drive then restore everything back. Some SSD manufacturers scrambled to build "garbage collection" into the drives firmware but this constant grooming actually shortens NAND life. Now TRIM is the perceived solution and, unfortunately it is misunderstood. TRIM is software built into the SSD's memory controller that recognizes commands from the operating system. The controller does nothing on its own. The operating system is responsible for issuing TRIM commands to the SSD informing the memory controller what blocks are no longer used and should be cleaned. As of 2011, only a few operating systems actually support TRIM. For those that do, there is still the problem that if the OS doesn't know what happened to the SSD outside of the OS's jurisdiction, it can not issue the TRIM commands to clean those things up. It may take awhile, but eventually any SSD will get dirty.
So what would I like Defraggler to do? Detect my SSD during a "Boot Defrag," read the free space areas and issue TRIM commands to cleanup the drive. Do nothing else: moving pagefile.sys, hiberfile.sys , BOOT, MFT and Directories is a waste of time. (Repairing them is another matter.) Naturally, if my SSD drive does not have TRIM support, skip all operations on the drive.
I do not want to repeat all this in the CCleaner forum, but it too needs to be SSD aware and prevent injurious Disk Wipe operations. Some users just don't know they should turn off Wipe and MFT Wipe on SSDs. Gratuitous protection might be welcomed.
