Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 6 down vote accepted

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.

share|improve this answer
I was actually curious about the GC routines and when they kick in but this explains it pretty well. After the controller marks the blocks as Reserve/Dirty, all the GC has to do is run during idle cycles and zero these blocks out. So the drive relies on the over provisioned flash memory for immediate writes and performs the clean up later. – skryl Apr 20 '11 at 0:43

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.

share|improve this answer
TRIM also comes into play with SSD GC (if the hardware and software supports it). It lets the OS tell the drive which bits the filesystems/volumes are (no longer) using. – Chris Johnsen Feb 18 '11 at 21:50
Yes, but then that wouldn't be a generic algorithm. – Erik Feb 18 '11 at 21:50
Even with over-provisioning there will come a point where all the drive's available memory has been written to at least once. After this point how is the drive able to determine which blocks are OK to erase during the GC cycle? – skryl Feb 20 '11 at 4:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .