From what little I've been able to dig up, not much, the FW on modern SSDs do implement TRIM as a NO-OP (No Operation) in certain situations. The TRIM command is considered advisory, meaning the SSD can choose to process it immediately, delay it, or treat it as a NO-OP based on its firmware and internal algorithms.
BUT, that doesnt mean it treats all TRIM commands as NO-OP and that in this situation where the PS3 doesnt issue any, it corectly handles all data sutuations optimally. Therefore it's possable that write amplifications will occure over time, decreasing performance and long term reliability.
The decision to treat TRIM as a NO-OP in certain scenarios is often influenced by factors such as minimizing write amplification and ensuring consistent and predictable performance. And it can vary between SSD models and manufacturers. So while modern firmware may help, it's not possable to know for certain if the one you're buying has the best FW. And let's be honest. People are buying cheap SSDs, which makes that less likely. Unless this is an industry standard and regulated to ensure all SSD controllers can handle themselves just as good without trim no matter what system they're put into.
It's a chance people are taking without knowing they're taking it.
I agree with most of this, with some tweaks.
For the higher end, in enterprise disk arrays they should all support UNMAP that always unmaps the blocks and never treat it as a no-op. This is not for wear-leveling but features such as thin-provisioning needs a "working" UNMAP.
Thin-provisioning is really important for very large disk-arrays as it allows a customer to spread the capital outlay out over the lifetime as the data grows instead of purchasing/commissioning all storage at once.
This also applies for disk arrays that are 100% HDDs!
For lower end or consumer hardware I think it is quite common that the device always implement UNMAP as a no-op. Several reasons for this, but I think the main ones are :
1, implementing a no-op is cheaper and takes less effort than actually implementing something.
2, PERFORMACE. Doing nothing is always faster than doing something and if doing nothing means that a pc-magazine benchmark runs faster then that is a cmpetitive advantage.
3, the standard allows it.
It is easy to write a test to check if UNMAP is implemented and if it is a no-op or not.
I did about 10 years ago, basically just writing some LBAs with known data, then UNMAPPing the blocks and finally reading them back to see if the content changed to be all zero.
I tested on a semi-large number of sd-cards, usb sticks and low-end ssd devices and virtually all of them just seemed to implement it as a no-op, which is fine because the standard explicitely allows it.
Things could be different now, who knows. If you want to test it, it is quite easy to make a test tool that checks it.
EDIT: informal talks with people in T.10 and specifically why that second proposal to add the FORCE bit failed suggested there were strong pushback from target/device vendors because of the hit to performance it would show up in benchmarks. That is all just discussions over a cup of coffee at a conference so ...
