Well, it doesn't actually say that it's GC is as good as trim - simply that - "(it has) built-in advanced background garbage collection. It automatically uses idle time to optimize data storage, so that disk writes are consistently fast. Since this technology is built-in, you'll get strong performance with Mac® OS X® and Linux as well." & "Multi-drive RAID configurations typically don't support TRIM. The built-in advanced garbage collection solves this problem and makes Performance Pro Series solid-state drives a great choice for RAID arrays." - which could be equally said about any SSD with GC... ...& i would bet large sums that you could back the SSD into a corner in non-trim with sufficiently high random data (based on the amount of free space) & insufficient idle time such that it the writes did suffer significantly - in the same way as happens with the M4 & C300 &... (the SFs generally retain write speed but lose read speed in the same scenario) You then do have to remember that all SSD warranties are based upon not exceeding a specific no of r-e-w cycles - if you go over them then there is no warranty at all, which is where longevity comes in 'if' you want to be writing to the things heavily. (also remembering that wear levelling & block combining & whatnot as part of GC uses up cycles) As to the worn flash cells becoming unreadable, my understanding is that what you've suggested isn't quite what's supposed to happen. Well, with current MLC, the gaps between the different voltages (known as the read margins) between the 4 possible states (00, 01, 10 & 11) narrows over time - in theory, as you say, to the point where the data would be unreadable - esp if left unpowered for a period. However to the best of my knowledge, there's supposed to be 2 methods in use to work around this to provide a more sensible minimum data retention time without power. (this is part of the JESD218 standard - which is what's used as the basis for rating endurance... ...though it's normally when a fraction of a percentage of the nand cells has become read only rather than all of the nand) 1. though afaik it's old hat, you limit the max no of writes to a cell to a fixed quantity that's less than or equal to the expected cell cycle rate - making each cell read once it reaches that point. 2. or the SSD looks at the read margins & makes cells read only when the gap narrows to a certain point. in both cases, this allows a far longer data retention than if the SSD controller were to just keep on using the nand until a literal breaking point - which is what you suggestion would allow to happen. [Edit] Plus, as a part of GC, wear levelling helps to maintain endurance. Looking up the specifics of the data retention for JESD218 (page 7), a client SSD needs to retain data for 1 year @ 30C with an Uncorrectable Bit Error Rate (UBER) of <=10^-15. This in mind, something i'd forgotten to include about the SFs is that their raise technology takes the UBER to ~10^-29 vs ~10^-15 for most other controllers... ...& can recover much larger quantities of data than standard ECC. i guess this is 'a' reason why LSi have bought out SF... ...& with LSi's in house testing being pretty damn good, i very much doubt that there'd be another repeat of the BSOD issues with the next SFs. i had seen this & potentially it's very interesting - though half the internet thought that a different version of IRST (or whatever the intel driver was called at the time) was giving this back in, if i remember correctly, March 2010 based on a similar document... ...it transpired that it simply allowed an SSD in non-raid to get trim commands if the controller was set to raid.