I keep seeing people say this, but I cannot see how this works? One assumes the garbage collection needs to look at the filesystem table to know what has been deleted and what hasn't, but in a Raid0 setup there isn't any specific filesystem table on any single drive for it to reference?
An SSD can infer which blocks are empty when the operating system gives it a write request to put new data in a filesystem block. What it will actually do is mark the NAND block as available for erasing, put the new data in an empty NAND block (SSD's have a decent percentage of extra inaccessible NAND just for this purpose) and change it's internal table for that filesystem block to point to the new location.
RAID makes no difference, the controller divvies up the work, but it's still at some point telling the SSD to put data in locations that the SSD knows already have data in ... Otherwise you'd never be able to write more than the capacity of the drive!
TRIM basically enhances a drives existing garbage collection routines. Instead of having to wait for a write request to come in and only being able to mark up which blocks are now free by which blocks it has been asked to store new data in, the drive gets told about ALL the blocks that can be marked for cleaning at the moment a file is deleted, which makes it much easier for it to keep a large pool of erased NAND ... and keeping a large pool of erased NAND as 'scratch space' is key to maintaining performance.
Garbage collection is nothing new for SSD's. Where routines have improved over the years is in becoming more proactive and intelligent at reorganising data so as to keep a larger available scratch space. Data needs to be reorganised because blocks can only be erased in large groups (128 blocks at a time), so the controller needs to copy data around (and update it's table) such that when those 128 blocks are erased nothing is lost.
The trade off for aggressive (i.e frequent and prepared to copy a lot of data to free up an erase block) is write amplification, since the same data can be written multiple times.
So the real benefit of TRIM support nowadays is not really performance (since garbage collection routines today work hard to keep sufficient scratch space to cope with normal usage patterns) but in reducing write amplification (less data will be copied unnecessarily, ergo less erase cycles used).
So far, NAND write cycles have not been an issue, even with the write amplification due to aggressive garbage collection firmwares and non-trim OS's I've seen very few reports of drives running out of cycles, so I feel it's safe to forego TRIM support.
