"garbage collection NOT equals TRIM in efficiency"
Can someone rephrase that?
idle garbage collection was actually implemented since 2-nd generation of SSD years ago. Each controller manufacturer have its own algorythm(s) for this. Basically they are the same - at idle time SSD controller goes thru drive, trying to determine which blocks are no more used and freeng them for further fast write.
On other side, TRIM command issued by OS directly and exactly tells controller which blocks are freed during say emtying the trash.
Theoretically GC can achieve state of exact knowledge of TRIM command - if it can fully analyze _ANY_ possible filesystem/partition type on drive.
Even in this theoretical situation it will be postfactum analisys and so - post-action on freeing blocks.
From other side - you will pay for that on-the-fly analisys with additional computations (which for example can be spended for data compression instead) performed on limited controller resources.
When OS issuing TRIM, instead of all this mess controller gets direct lists of blocks to set free.
So we have direct knowlege vs some more or less efficient analysis situation and additionally anyway we save on spent (in controller) computing power. Plus we get immediate(or even forvard-looking) action for TRIM vs post-action (read delayed) with idle GC
So there are a lot of situations when even theoretically ideal (impossible in real life) GC will lose to TRIM
Yes, new SF 2xxx GC is fantastic. But its still worse than trim. Problem is - it just need time to do its job. And if there'll be no that time?
Ask SandForce or OCZ or any about write efficiency under
a) heavy load of random _concurrent_ writes
b) writes when there are no (marked)free (ie write-ready) blocks on drive
с) all above with uncompressible data
with and without trim
on trim enabler. In short - it works and it no less safe than using Apples own SSDs. There are no(zero) cases with data corruption pinpointed to trim enabler. In more words - read what I wrote in post above
