When a file is deleted from a computer, almost all operating systems delete the table of contents entry, but not the actual data blocks from the storage media. For flash SSDs, this leaves superfluous data blocks on the flash media that eventually must be overwritten. SSD TRIM
Before we go further in talking about SSD TRIM, let’s take a step back.
NAND-flash devices use the “program-erase cycle” in order to accomplish writes. This is also sometimes known as the “write cycle.” Basically, when data needs to be written to a NAND-flash page, the page must be empty. If there is data on that page, the low-level flash controller must read the existing data from the page, erase the page, merge the new data with the existing data and then write the page. This process makes reads and writes “asymmetrical” with respect to the number of steps needed to accomplish the operation. All of this takes place on the device at a lower level than what the user can see.
Keep the program-erase cycle in the back of your mind for a moment, and now think about the process for deleting data on a computer. In nearly every computer operating system, when a user deletes a file, not much actually happens. The operating system looks up the file information in its table of contents and, when it finds it, deletes that entry from the table of contents and marks the data block addresses as available for writing. However, it generally does nothing with the actual data blocks containing the contents of that file that are on the storage device. Sometime later, when the user creates a new file and saves it, the operating system looks for available blocks and stores the new data on those blocks.
Now consider the program-erase cycle for SSDs. In the case described above, the operating system now wants to write new data to available blocks on the storage device. It issues the write command to the device and the NAND-flash SSD may find that some of the flash pages are not empty. So the SSD has to first erase those non-empty pages and then proceed with the write operation.
What if the operating system could erase those SSD pages in advance, so when it was time to write data to those pages, they were already blank? It turns out that there is a function built specifically for this, known as TRIM. SSD TRIM is a command in the SATA specification that tells the SATA SSD to begin the background process of erasing available SSD pages. This process of erasing available pages in SSDs is sometimes known as “garbage collection.” SATA TRIM is supported and enabled in Windows 7 and Windows Server 2008 R2 for SATA SSDs by default. SATA TRIM is also supported in some versions of Linux for specific file systems (EXT4, for example) but is not enabled by default. SATA TRIM is also supported for Apple OS X Lion 10.7 for Apple-branded SSDs only.
This is great news if you have SATA SSDs and are using an operating system that supports SSD TRIM. However, what if you have enterprise SSDs that have an interface other than SATA, such as SAS or PCI-Express? Or what if SATA SSDs are behind a SAS RAID controller or included in an external enterprise disk array connected via Fibre Channel, iSCSI or some other interface?
For these, there is good news and bad news. There is a SAS/SCSI command known as UNMAP that is the equivalent for SATA TRIM for SSDs. The UNMAP command is supported in the newer SAS SSDs coming onto the market. However, most SAS RAID controllers and external storage arrays haven’t implemented UNMAP yet. When host servers communicate with a SAS RAID controller, external Fibre Channel or iSCSI storage array, the devices (LUNs) are presented as something other than SATA, so TRIM commands will not be used. PCI-Express SSDs are not SATA so TRIM is not usually supported. However some of the PCI-Express SSD vendors are aware of TRIM and may be able to support it with their driver.
The lack of TRIM support does not necessarily mean that SAS RAID controllers and external storage arrays do not perform garbage collection on their SSDs, it just means that they have to accomplish it a different way. External storage subsystems that have SSDs in them do perform garbage collection, but this step is triggered by the storage system itself and not by specific SATA TRIM requests issued by the host servers.
You can expect progress to be made for UNMAP over the next year or two, as UNMAP makes its way from the drives to the RAID controllers and external storage arrays. You can also expect more PCI-Express SSD vendors to support TRIM or its equivalent in the future.
About the author: Dennis Martin is president at Demartek LLC, an Arvada, Colo.-based industry analyst firm that operates an on-site test lab. He can be reached at firstname.lastname@example.org.
This was first published in April 2012