Garbage Collection Algorithms Coming For SSDs

MojoKid writes "A common concern with the current crop of Solid State Drives is the performance penalty associated with block-rewriting. Flash memory is comprised of cells that usually contain 4KB pages that are arranged in blocks of 512KB. When a cell is unused, data can be written to it relatively quickly. But if a cell already contains some data, even if it fills only a single page in the block, the entire block must be re-written. This means that whatever data is already present in the block must be read, then it must be combined or replaced, and the entire block is then re-written. This process takes much longer than simply writing data straight to an empty block. This isn't a concern on fresh, new SSDs, but over time, as files are written, moved, deleted, or replaced, many blocks are a left holding what is essentially orphaned or garbage data, and their long-term performance degrades because of it. To mitigate this problem, virtually all SSD manufacturers have incorporated, or soon will incorporate, garbage collection schemes into their SSD firmware which actively seek out and remove the garbage data. OCZ, in combination with Indilinx, is poised to release new firmware for their entire line-up of Vertex Series SSDs that performs active garbage collection while the drives are idle, in order to restore performance to like-new condition, even on a severely 'dirtied' drive."

The logical next step...

[Joce640k]

A weakness was found in first generation drives, the second generation drives fixed it.

Film at 11.

Who had to creative/hates "defragmentation"?

[sznupi]

"Garbage collection" has already quite different usage in CS. And while what has to be done to those SSDs isn't technically the same as defragmentation on HDDs, it is still "performing drive maintenance to combat performance-degrading results of prolonged usage, deletion of files".

Re:At what cost?

[slimjim8094]

Possibly shorter drive life. If each cell can be rewritten 100,000 times (don't remember exactly) then - for exactly the same reason you're doing this in the first place (rewriting an entire cell on every write) you'll be wearing out the cell.

Probably a net gain, though. This and wear-leveling algorithms probably will make drives last longer.

Don't be quite so cynical. Usually I'd agree with you - but SSD (not flash) is so new that improvements can be made for free by just changing some techniques.

Re:The logical next step...

[amRadioHed]

How would this make a difference? The blocks would have to be wiped out next time they are written to anyway, the only difference here is that the blocks are cleared during idle time so you don't have to wait for it.

Re:At what cost?

[Anonymous Coward]

Needn't be. Suppose I have 128Kb free wherein I do garbage collect. I could still write a 4 block to it, if I had not done GC before.
Thus, the shorter lifetime.

Re:Do cleanup in the OS

[smallshot]

I disagree with your list of reasons why the OS should do it:

1. "idleness" should refer ONLY to the SSD not being used, not the OS being idle, in which case they both have approximately the same information.
2. The OS should NOT hold unimportant writes for very long, and doing GC during this time does not change the possibility for important writes to be necessary
3. I agree here. However, on battery power, I would expect an SSD would be sent to standby very quickly as if it were physically spinning, in which case the SSD firmware should know better than to do GC during standby, and with a definition of idle being 5+ minutes of zero-usage, it could be effectively the same as the OS not doing it on battery power. But I am only speculating

On my list of AGAINST the OS doing GC i have:

1. EVERY OS would have to support it in their next update to be as effective as having GC done in the firmware.
2. OS software engineers are not likely to know the best way to design a GC for SSDs, leave it to the manufacturers who build the thing.

There are some pros to letting the OS manage it, but I think it's riskier. I would suggest the firmware do the GC but have an interface for the OS to override the GC for flexibilities sake.