....
The main issue with SSD's is wear over time causing drops in the random write performance as the drive cannot write without first re-arrange content to free up blocks. ....
You are intertwining two different issues.
The first issue is that the memory cells on flash drives wear out each time a cell is erased. That is they get to the point where they fail to store data correctly. The effect of that is your twofold. Minimally that the amount of storage on the drive goes down over time. (your drive gets smaller. ). Worse case you start to loose data through corruption. There is an illconcieved notion that SSD drives don't wear out. That notion was built on cases where folks were using RAM to build SSDs. Flash based SSDs
do wear out pure and simple.
Because of this first issue there is a second issue. Flash drive controllers take active measures to spread the erasures over multiple different cells. If you write to logical block address 42 six times in reality at the physical level the drive may write to six different cells for each one of those times. There are tricks were they can avoid the erasure but they don't work all the time. That issue boils down to the need for the drive to have a large pool of memory cells that it knows it can erase and reusue. With a large pool and some other tricks it can keep the write performance high over an extended period of time.
So writes are bad for the long term health of a SSD drive. How bad depends in part how clever the controller is and how much the cells resist wearing out. Recently there have been some improvements on the wear front.
The TRIM command is a "nice to have" but it isn't necessary in increasingly more cases were the controllers aren't anemic in parallel processing capabilities and/or "smarts". TRIM helps hide the latency between the normal read/write flow from/to the disk and doing garbage collection work (prepping cells avoiding erasing previously to being written to later. ). The TRIM command serves a two fold purpose. First it stops read/write requests from being issued ( that's right it slows down read/writes because if sending a TRIM command can't be sending a read/write command. ). The second impact is that it sends more information to the drive so its garbage collector can be applied to a broader set of cells ( so the pool of erased and prepped cells are larger. ). Most file systems don't "zero out" file blocks when file is abandoned. The are unlinked and just left with their old contents. TRIM just communicates to the disk that they have been abandoned. (note that if those cells are proactively recycled the ability to do disk recovery in a corrupted file system metadata situation is removed. )
TRIM isn't as necessary because for every block you skip to write to another the one you just skipped can be potentially added to the free list. (e.g., remap logic address 42 to another empty/prepped ). As long as get some spare cycles to press the one just left it should be read by time its turn in the reuse list comes due. If you create a long enough "reuse later" queue it will be ready by time need another new one.
The only place that fails is if somehow have an extremely long list of write that blow out your "reuse later" queue. For example all of a sudden need to write out a 10GB file on a 50GB disk without any reads in between at all. That just doesn't happen very often if have provisioned the SSD capacity correctly and have a smart controller.
You can easily create a larger pool of prepped cells by just not filling up the drive to a relatively high water mark. Usually these benchmarks consist of filling the drive up till it full and showing how the drive slows down. You can avoid the latter by simply just not doing the first.
So for example. If you require on average 50GB of scratch space your drive will do better if only fill 25% of it than if you fill 90% of it.
The OWC drives with approx 30% over provisioning aren't going to help much if your write bursts are in the 10% range and you had alot of data squatting on the most of the memory cells keeping them occupied. Over time you would be killing off the drive faster in a very high write scratch environment.
