Mailinglist Archive: opensuse (671 mails)

< Previous Next >
Re: [opensuse] Idle Time Garbage Collection (ITGC) On (openSUSE) Linux
  • From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
  • Date: Sun, 12 Jun 2011 13:58:50 -0400
  • Message-id: <>

Since I don't recall this being discussed here before, I wrote a wiki
article about it.

Please review and correct:


On Sun, Jun 12, 2011 at 1:39 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
On Sun, Jun 12, 2011 at 12:45 PM, Randall R Schulz <rschulz@xxxxxxxxx> wrote:
On Sunday June 12 2011, Randall R Schulz wrote:
On Saturday June 11 2011, Cristian Rodríguez wrote:
El 12/06/11 00:57, Randall R Schulz escribió:

My next   question relating to using SSDs on openSUSE is whether
they enable or implement the so-called Idle Time Garbage
Collection used by SandForce SSD chips (such as the SandForce
1222 chips on the RevoDrive x2 card I bought).

afaics, "Idle Time Garbage Collection" is implemented in the

Yes, that much I understood. I just couldn't see how it could "garbage
collect" anything if the OS didn't tell it which logical sectors it was
actually using.

Nothing I've found has made it clear whether this is something
that requires OS / filesystem support, but the descriptions I've
found (which have been very sketchy) suggest filesystem support
is required.

TRIM needs support in the filesystem, ext4 has a support for it,
using the "discard" mount option, which is apparently on its



The only thing I can't make sense of is how the controller knows
which sectors (or pages or blocks or whatever they call them on SSDs)
are being used for file contents and which are not without filesystem
interaction. One description I found said the controller "asks the
operating system" if a block is in use.

After reading a rather contentious thread on
[1] I think I understand, at least in very rudimentary terms, how the
ITGC thing works.


[1] <>

Randall Schulz

I just read it.  Very uninformative.  It talks not at all about the
core issue of data overwrites and how that causes partially valid EBs.
 And that a "Garbage Collector" is needed even in the absence of file

Think about what one poster actually said.  He ran IOmeter against a
raid device with SSDs behind it and his performance sucked.  Then the
next morning it was good again.

There is no way a single SSD which is part of a RAID can interpret the
filesystem metadata and determine which pages are free.

And few if any Raid Controllers pass down trim commands yet.

Especially if its Raid5 or 6, you have to trim in units of stripes.
ie. Either an entire stripe is valid, or the entire thing is invalid.
That the way Raid5 and 6 are designed  There is no way a single raid
component drive can make that determination.

OTOH, if there is lots of overwriting going on due I/Ometer writing to
the same sectors over and over then each overwrite leaves a partially
used EB behind.

Letting the SSD consolidate all those partial EBs into full EBs
overnight would cause the performance increase the user saw.


Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
CNN/TruTV Aired Forensic Imaging Demo -

The Norcross Group
The Intersection of Evidence & Technology
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups