Isso mesmo Alan, neste link ( http://goo.gl/A2aw5h ) existe uma tabela dos vários modos para tentar contornar o problema e eles falam do idle garbage collector que fabricantes como OCZ adotam indicando que é menos eficiente que o TRIM.
Background garbage collection
The process of garbage collection involves reading and rewriting data to the flash memory. This means that a new write from the host will first require a read of the whole block, a write of the parts of the block which still include valid data, and then a write of the new data. This can significantly reduce the performance of the system. Some SSD controllers implementbackground garbage collection (BGC), sometimes called idle garbage collection or idle-time garbage collection (ITGC), where the controller uses idle time to consolidate blocks of flash memory before the host needs to write new data. This enables the performance of the device to remain high.
If the controller were to background garbage collect all of the spare blocks before it was absolutely necessary, new data written from the host could be written without having to move any data in advance, letting the performance operate at its peak speed. The trade-off is that some of those blocks of data are actually not needed by the host and will eventually be deleted, but the OS did not tell the controller this information. The result is that the soon-to-be-deleted data is rewritten to another location in the flash memory, increasing the write amplification. In some of the SSDs from OCZ the background garbage collection only clears up a small number of blocks then stops, thereby limiting the amount of excessive writes. Another solution is to have an efficient garbage collection system which can perform the necessary moves in parallel with the host writes. This solution is more effective in high write environments where the SSD is rarely idle. The SandForce SSD controllers and the systems from Violin Memory have this capability.