Scroll to Top

It may sound crazy, but hard disk drives (HDDs) do not have a delete command. Now we all know HDDs have a fixed capacity, so over time the older data must somehow get removed, right? Actually it is not removed, but overwritten. The operating system (OS) uses a reference table to track the locations (addresses) of all data on the HDD. This table tells the OS which spots on the HDD are used and which are free. When the OS or a user deletes a file from the system, the OS simply marks the corresponding spot in the table as free, making it available to store new data.

The HDD is told nothing about this change, and it does not need to know since it would not do anything with that information. When the OS is ready to store new data in that location, it just sends the data to the HDD and tells it to write to that spot, directly overwriting the prior data. It is simple and efficient, and no delete command is required.

Enter SSDs
However, with the advent of NAND flash-based solid state drives (SSDs) a new problem emerged. In my blog, Gassing up your SSD, I explain how NAND flash memory pages cannot be directly overwritten with new data, but must first be erased at the block level through a process called garbage collection (GC). I further describe how the SSD uses non-user space in the flash memory (over provisioning or OP) to improve performance and longevity of the SSD. In addition, any user space not consumed by the user becomes what we call dynamic over provisioning – dynamic because it changes as the amount of stored data changes.

When less data is stored by the user, the amount of dynamic OP increases, further improving performance and endurance. The problem I alluded to earlier is caused by the lack of a delete command. Without a delete command, every SSD will eventually fill up with data, both valid and invalid, eliminating any dynamic OP. The result would be the lowest possible performance at that factory OP level. So unlike HDDs, SSDs need to know what data is invalid in order to provide optimum performance and endurance.

Keeping your SSD TRIM
A number of years ago, the storage industry got together and developed a solution between the OS and the SSD by creating a new SATA command called TRIM. It is not a command that forces the SSD to immediately erase data like some people believe. Actually the TRIM command can be thought of as a message from the OS about what previously used addresses on the SSD are no longer holding valid data. The SSD takes those addresses and updates its own internal map of its flash memory to mark those locations as invalid. With this information, the SSD no longer moves that invalid data during the GC process, eliminating wasted time rewriting invalid data to new flash pages. It also reduces the number of write cycles on the flash, increasing the SSD’s endurance. Another benefit of the TRIM command is that more space is available for dynamic OP.

Today, most current operating systems and SSDs support TRIM, and all SandForce Driven™ member SSDs have always supported TRIM. Note that most RAID environments do not support TRIM, although some RAID 0 configurations have claimed to support it. I have presented on this topic in detail previously. You can view the presentation in full here. In my next blog I will explain how there may be an alternate solution using SandForce Driven member SSDs.

Kent Smith is senior director of marketing for LSI’s Flash Components Division, overseeing all outbound marketing and performance analysis. Prior to LSI... Read more

Tags: , , , , , , , , , , , , ,
Views: (22123)

5 comments on “Did you know HDDs do not have a “Delete” command? That is why SSDs need TRIM

  1. Hi Kent,

    Great article. Quick question. I have 4 disks with the following setup:

    Disk 1: SSD (contains Windows 7 64 bit OS)
    Disk 2: HDD (contains apps)
    Disk 3 & 4: HDD (contains data and is set in RAID 1 mode)

    I have enabled RAID in BIOS. TRIM is enabled as well by Win 7. Since TRIM is not supported in RAID, does that mean it is not working in my setup? This has always intrigued me because my SSD is not part of the RAID setup. Only the two HDDs that contain my data files are part of the RAID array. I would appreciate your feedback. Thanks for your time.


    • Ken, the question of TRIM and RAID comes up a lot. There are some combinations that are reported to be working better than others through a RAID configuration, but in your situation there should be no issue whatsoever. As you described your setup, the SSD is connected directly to the motherboard (I assume) on its own connection and not through a host adapter card. As long as that direct connection is not being managed by the host RAID you should have no trouble with TRIM getting through to the SSD. In other words, only the drives set up with RAID would have a problem, but those are HDDs that don’t need TRIM, so you should be working at optimum TRIM performance.

      • Thanks for the detailed reply, Kent! I feel much better now that I know TRIM is fully in effect! Couple of questions:

        1. I found this on a forum:
        “AMD RAID driver doesn’t pass TRIM to SSD. I came to the conclusion that because of the DuraWrite technology in Sandforce drives, TRIM doesn’t have nearly the impact that it does on drives with other controllers like Indilinx or Intel. The DuraWrite wear leveling algorithm doesn’t pass through TRIM commands directly like on other drives so Sandforce drives really rely heavily on the internal GC algorithms. So eventually I came to the conclusion that since TRIM isn’t going to have a huge impact anyway, I was much better off with leaving my SSD on SATA3_5 and leaving ports 4 and 5 “As SATA Type” to preserve the Native Command Queuing.”

        Do you have any comments on the above? My motherboard uses an AMD SB850 SATA controller which also controls the RAID for my two HDDs and uses the AMD RAID driver.

        Secondly, my SSD uses the dreaded SF2281 controller chipset which has been plagued with BSOD issues. I have had it for about a year and recently started getting frequent BSODs. Looks like I was on version 3.32 and was asked to upgrade the firmware to version 5.07. It’s been a couple of days since I did the firmware upgrade and so far no BSODs. My question is, has the SF2281 issues been fully resolved or does it have an inherent issue that will eventually come up again (BSOD) at some point. My BSOD started happening upon sleep/wake mode. Looks like one of the fixes in 5.07 was COMWAKE which was maybe released to fix the BSOD resulting from this issue? Some others have said, it is a silicon issue on the SF-2281 for which there is no permanent fix. I was just wondering if you have any comments on this.

        Thanks so much for taking your time, Kent! Much appreciated!


        • On the AMD question, if an SSD is being used in a RAID environment, it is up to the RAID driver to pass the TRIM command to the appropriate drive in the RAID array. If you have a single SSD as a standalone device, there is no reason for the driver NOT to pass it through. I don’t know of any situation where a single device will have trouble receiving TRIM. As for DuraWrite technology, because of the way it generates additional free space with most data types, that increases the dynamic over provisioning which helps to keep performance high. What people misunderstand is that with very low entropy data, DuraWrite may already give you the maximum advantage from dynamic over provisioning and so the TRIM command does not have any more that it can improve; it is already at its maximum benefit. The statement that “DuraWrite does not pass through TRIM commands” is completely inaccurate. DuraWrite and TRIM are complimentary in that they both increase dynamic over provisioning as I mentioned above. As far as I know, the AMD RAID driver should pass the TRIM command to your lone SSD with no trouble.

          On the SF-2281 controller question, I always find it interesting that a problem from nearly two years ago seems to be very misunderstood. I will point out that Windows on its own will generate BSOD for more reasons that I can list here. I have also researched the problem over the last two years and found just as many competitive SSD controllers showing up with BSOD issues as were reported with the SF-2281 back then. Back when the SF-2281 first came out there were actually a combination of issues that were related to Windows BSOD from firmware and physical SSD manufacturing (not the controller silicon). I believe SandForce received the most press on that topic because of the huge percentage of market share we held and still hold today. The firmware was updated and provided to all of our SSD manufacturers a few years ago. Our SSD manufacturers reported the problem fixed with the firmware updates and from the changes in some vendor’s manufacturing procedures. Again this was never an issue with the silicon itself. It is hard to tell if a particular change in 5.0.7 improved your situation, but it has been a very long time since anyone has actually seen a SandForce controller with BSOD with any of the updated firmware. If your SSD started showing a problem and you were still on version 3.32, then it is possible something changed in the OS to possibly cause a timing issue when coming out of sleep that was fixed a long time ago. I expect you should not see any BSOD as a result of the SandForce SSD controller, but remember Windows will BSOD for many reasons other than the SSD anyway.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>