So over the course of the day there are roughly 50 x 10MB files lying around that are all deleted data. Half a gigabyte of additional data, compared to the 10MB file you are working on. Without Trim, the SSD will perform GC on all that data, reading and writing and tidying up into nice neat blocks. With Trim, it will simply ignore that data in the GC process and write amplification is significantly reduced.
Writing 10MB files should not cause any significant write amplification, TRIM or no TRIM!
NAND block sizes (i.e. the smallest unit that can be erased at once) varies by the type of NAND used, but its on the order of 256K - 2MB. Since a 10MB file would fully occupy multiple NAND blocks, there wouldn't be any need for GC, except perhaps where the edge of the file crosses a block boundary.
Modern SSDs also include "caches" made of SLC NAND, which of course has both a longer life-cycle and smaller block size than the MLC/TLC/V-NAND that make up most of the storage. Small chunks of data that are frequently written can go to this SLC area rather having to GC and erase full blocks of the regular NAND.
Also, TRIM does
not prevent the need for GC! You are still always going to have small files that part-occupy NAND blocks. Sure, it may help out the SSD's firmware a little in GC'ing more efficiently, but some degree of GC and write amplification will always occur simply because of the mismatch between NAND block sizes and OS-level HDD block sizes.
So I stand by the claim that the
primary benefit of enabling TRIM is the performance improvement resulting from allowing block erasure (and associated GC) to be performed in advance, in the background, rather at the time you write data. It's true that in some scenarios TRIM may also reduce wear somewhat by improving the efficiency of GC. But given the other features that SSDs use to reduce this, and that GC must to some extent still happen anyway, I don't think it makes a big difference.
