How does SSD garbage collection work?

Question

Correct me if I'm wrong but doesn't the block bitmap (which keeps track of free blocks on a disk drive) vary for different file systems (both location and structure wise)? So how can OCZ have a generic algorithm for garbage collection without considering the file system being used?

Answer 1

SSDs have more blocks beyond what the stated capacity would indicate. These blocks are used as part of the wear-leveling process as well as fault replacements as blocks completely wear out. Because of this, the SSD's controller has to keep track of which blocks it sees are currently presented to the system as which logical blocks.

In the absence of TRIM, when a write arrives for a dirty block (one that already has data in it as far as the SSD is concerned) one of two things happen:

1. The Controller reads the old block into local memory.
2. The Controller modifies the bits needed.
3. The Controller rewrites the entire block to the old block

However, because of wear-leveling, this is more likely:

1. The Controller reads the old block into local memory.
2. The Controller modifies the bits needed.
3. The Controller writes the entire block to a new block in the reserved portion
4. The Controller updates its logical mapping for the new logical-block:physical-block pair.
5. The Controller flags the old block as part of Reserve.

The key thing here is that the SSD controller itself is also keeping a bitmap of blocks. Unlike a filesystem bitmap it's matching logical blocks to physical blocks, and that can change every time a write happens.

Answer 2

By over-provisioning. OCZ adds e.g. 7% more flash than what the drive needs. These 7% are used to do wear leveling and replacement of faulty blocks, but can just as well be erased during idle time avoiding the erase-write cycle that you'd otherwise incur.