SSD - a Defrag challenge

[PJS922]

Great tools guys! Just a suggestion to put in a Lock-out or Hide drive so defragger could not be run on SSD's.

I know your tool is small and compact and would not want to compromise that, but if it could grey out or hide

drives after installation, it could benefit some users. I used the exclude tab to exclude the C:\*, but it still

shows, analizes, and looks like it may run "don't want to see if it will". SSD's look like a mess if you analize,

and I know someone here will try, so I hide the defrag program. Again, just an idea, and good products.

[mr don]

Great tools guys! Just a suggestion to put in a Lock-out or Hide drive so defragger could not be run on SSD's.

 

If they implement this, it should be optional.

There are occasions someone would want to run it on an SSD.

I would, primarily for testing reasons...

 

Don

[PJS922]

Agreed, just an option in the menu to hide a SSD, or any drive you don't want to show!

"Exclude" still allows it to show.

[Rob Defraggle]

Agreed, just an option in the menu to hide a SSD, or any drive you don't want to show!

"Exclude" still allows it to show.

 

This would be generally useful, I have at least 9 drives shown of which 4 are just totally pointless having in the list, anyone with removeable storage is going to face this, inserting USB flash drives adds to it.

 

Another reason is that I've noticed you cannot remove USB memory disks safely in the usual way, when Defraggler is started using the Win7 system tray icon. It claims the drive is in use, though I've found ejecting the drive from the "Computer" window, allows one to "Continue" from a warning popup, and actually does then allow safe removal according to the icon, with Defraggler not seeing the drive as mounted anymore.

[SolarFox]

I run Defraggler on My SSD once per month but just a Quick Defrag... That mean only files are fixed on place where are they already. defragmenting was done in less than 10 seconds. That`s all. That should not kill a drive. 10 seconds one per month....

[kroozer]

Defragging an SSD defeats the purpose of the Flash Controller which distributes the writes evenly across all the flash blocks.

This wear leveling prevents one block from wearing out prematurely.

 

Nor will you see any performance improvement by defragging an SSD.

[Augeas]

I don't think that it can beat the disk controller, as defraggers will re-arrange the logical cluster numbers and the controller will just go ahead and put the data wherever it feels like (Which is why you can't overwrite a file on SSD).

 

What would be sooper would be a defragger for SSDs that defragged the LCNs, and the SSD controller just remapped its er, maps without moving any data. Thus logical I/O would be reduced with no wear on the SSD. But that's pie in the sky.

[Rob Defraggle]

I run Defraggler on My SSD once per month but just a Quick Defrag... That mean only files are fixed on place where are they already

 

The "fragmented" new files will be re-written pointlessly as well as the "location" meta information for the files and cause extra erase cycles to the flash pages, with especially small files causing a write amplification effect (a 4KiB write often requires read and write of whole Flash 512 KiB page). SSD's tend to slow down as pages are re-written, rather than using fresh unused pages (hence TRIM command to tell SSD controller that blocks are unused and allowing creation of lists of empty flash pages).

 

Many OS writes can be buffered and deferred, allowing writes to be coalesced to full flash page sizes, which may not be true, when re-locating a file.

 

Buy an SSD so you can forget about defragging, you've no spinning disk or disk arm to move, causing long seek times.

[CaribCruiser]

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.