SDB:SSD Idle Time Garbage Collection support
Related articles
Terminology
Erase Block - EB - SSDs are built from Nand gate techonology. The basic building block is a Nand storage chip that works in blocks of data. Within the Nand-chip is an erase block capability. The erasing technology does not allow for a portion of a erase block to be erased. It is all or nothing. Thus the term Erase Block, or EB has come to be known as the smallest size block the Nand-chip can erase. Typically EBs are much larger than traditional sectors or even filesystem pages. 128KB is the most common size of EB currently.
Discard, UNMAP, and TRIM: These are three terms often used to interchangeably describe this same basic functionality.
Discard is the linux term for telling a storage device that sectors are no longer storing valid data and applies equally to both ATA and SCSI devices. ie. For ext4 filesystems, there is a discard mount option, not a trim or unmap option.. Historically this feature has not existed, but recently SSD manufacturers have requested this ability to increase the performance capability of their designs and SCSI array manufacturers have requested similar functionality to better support thin provisioning.
Thus it would be typical to discard small sector ranges with a SSD, but only large ranges with a SCSI array. ie. Some SCSI arrays may clip ranges to 4 MB boundaries. The implementation of array specific as to how ranges are clipped.
TRIM is the actual ATA-8 command that is sent to a SSD to cause a sector range or set of sector ranges to be discarded. As such it should only apply to ATA devices, but is often used generically. Given the prevalence of ATA devices, trim is often the most used of these terms.
UNMAP is a SCSI specific command that is similar in nature, but primarily intended to support thin provisioning. UNMAP too is often used as a generic term as opposed to reserved for SCSI devices.
SCSI also supports WRITE SAME which can also be used to implement discard functionality. WRITE SAME for now appears to only be used when it specifically applies.
Why do SSDs need garbage collection?
In general all modern SSDs need to have a Erase Block (EB) consolidator. Modern SSDs have EBs which are typically 128KB, but they allow those EBs to hold non-contiguous pages of data.
Some SSD manufacturers refer to it as Garbage Collection. SandForce in particular calls it Idle Time Garbage Collection.
In regards to SSD EB consolidation, the key thing to understand is EB re-use is all or nothing. To re-write any of the data, you have to Erase the entire EB, then re-write all of it. In very slow / cheap thumb drives, they live with the restriction and write speeds can be as slow 10s of MBs/minute.
In a decent SSD, they have developed much more complicated algorithms to make the drive much more responsive. Not only are they typically as fast as rotating disk, they are often far faster for random I/O applications.
So lets assume a SSD tracks and maps data in 4KB pages, even though it has a 128KB EB. So a newly allocated and written EB would typically have 32 4KB pages in it.
If some of the pages are overwritten by normal filesystem use, the most efficient thing for the SSD to do is mark the overwritten pages in the allocated EB free, and queue the new pages to go to a newly allocated EB. When the SSD has 32 pages of new data queued, it will allocate a new EB and write out the data. Of course it also updates the logical to physical mapping tables when this happens.
Seems pretty smart, but think about the original EB. Over time as data is marked stale due to overwriting it goes from 32 of 32 pages in use to less and less pages of valid in use data pages. At some point the SSD controller says, what a waste of space, let me consolidate some of these partially used EBs.
You can see EB consolidation is needed even in the absence of OS level support. And it does not need to understand the filesystem layout etc.
The trouble is if your drive is 100% full or close too it, the EBs will all tend to be fairly full as well, and so you can end up with all the EBs in use with 75% or more good data. Having a consolidator be efficient with such a high average in-use percentage is very difficult.
Thus the concept of trim was created a in the 2007/2008 timeframe. The goal of the trim command is for the SSD to have greater knowledge of what pages are really in use, vs. not in use. And with that knowledge be able to more efficiently consolidate EBs for background erasing.
Thus Erase Block consolidators such as SandForce's Idle Time Garbage Collection are implemented in the SSD and do not need Linux support to work, but ensuring your SSD is "trimmed" will allow the SSD know better what data pages are free and thus allow the process to work better.