Hi Kevin K!

 On 2015.05.06 at 18:52:42 -0500, Kevin K wrote next:

> > On May 6, 2015, at 6:31 PM, Vladimir Mosgalin <[log in to unmask]> wrote:
> > 
> > Alternative to TRIM-aided GC is Idle Time Garbage Collection (which you
> > could see on Plextor), which actively scans data in background, finds
> > empty blocks (zeroes) and marks them as free. Well probably more
> > complicated than that, but it's the idea. 
> 
> A quick search indicates that Idle TIme Garbage Collection is just another term for garbage collection.  And I don’t see how it can work as well without TRIM as with TRIM, unless massively over provisioned.  There is still the issue that, at the file system level, you may now that you just deleted a 1GB file that fully fills a whole lot of EBs.  Without trim, the controller can’t know that the blocks aren’t in use until the OS attempts to write to those blocks.  if the controller needs to make space, it will have to copy the stale data that it doesn’t know isn’t used anymore.  Now, a continous write to a whole EB’s worth of data (still stored in DRAM on the drive), it can see that the whole block can be marked as unused, and freed later.  

I've posted the graph, you've seen it. You can find similar graphs on
other sites exploring the matter (anandtech, tom's hardware and so on).
There are drives which restore performance to original or near original
without aid of TRIM. They are consumer-grade with typical 7-15%
over provisioning, just like any other drive. Not enterprise models with
40-50% over provisioning.

If you want graph with more drives there is one here
http://www.xbitlabs.com/articles/storage/display/plextor-m5-pro-m5s_6.html
You can clearly see that some drives can't restore performance without
TRIM, and some restore most of it (up to 100% in case of M5P, which
isn't here) after some idle even without TRIM.

Of course, massive over provisioning is still a great feature of
enteprise drives. There is performance degradation on any kind of drive
even with the use of TRIM before GC is performed (explored here in detail:
http://www.tomshardware.com/reviews/m5s-256gb-ssd-benchmark,3252-7.html)
However it isn't so on massively over provisioned drives (Anandtech has
excellent graphs of this in articles about enterprise SSD drives, how
over provisioning lets drive to show high write IOPS numbers at any
moment).

Here is another example of drive restoring most of its performance
without TRIM:
http://www.anandtech.com/show/6337/samsung-ssd-840-250gb-review/11
(as you can see, it behaves in pretty complicated way, however it's
clear that GC works very well even without TRIM).

> 
> I’m not sure what the zero blocks you are referring to means.  If you write a whole bunch of zeros, is it marked as unused?  Even if contained in a file?  You really can’t mark obsolete data as zeros since you can’t rewrite until you erase first.

I think I used the wrong wording. I'm sure it would mark zeroes as
unused (yes, even in a file - it just erases these blocks and unmaps
them, when you read from unmapped LBA the drive returns you zeroes), but
generally these algorithms are more complicated. Writing zeroes isn't
recommended (http://www.lowlevelformat.info/zero-filling.aspx) - it
might work for some SSDs, of course, but still risky.

I don't really know the details of how TRIM-less GC works in complicated
cases, but it's obvious from performance graphs that it really does work
on certain drivers and doesn't work too good on others.

Regarding the term "Idle Time GC" - yes it is used for describing any
kind of background GC, whether TRIM-aided or not by some manufacturers.
There is nothing I can do about that. I used it the way it's often used on
some hardware sites and forums, but there are manufacturers who use this
term in a different way...

-- 

Vladimir