some drives will use unaloccated space as SLC cache, some can work with just free space
either way with provisioning you dont loose performance once you fill up your drive
Do you have a source to back up the first claim? I am genuinely curious if (and, if so, why) a drive differentiates between unpartitioned free space and partitioned (but trimmed) free space. From the drive's perspective, neither contain user data and can be cleared whenever, and used however the controller sees fit. To even determine what space is or isn't partitioned, the drive would have to be actively examining the partition table. I do not know whether this is the case or not.
To my knowledge, virtually all modern consumer SSDs utilize some form of SLC caching but the implementation can vary greatly. I'm pretty sure the ones that use a dynamic
SLC cache adjust the size based on how much free space the controller knows it has available to it (trimmed free space + overprovisioning).
As to your second claim, yes and no. Even with overprovisioning, you're still likely to lose some performance, unless you go with a ridiculously large amount. The performance penalty just gets more severe the fuller the drive gets. Overprovisioning mainly prevents
you from completely filling your drive.
if you delete some stuffs to get some free space, data will still remain on drive (until it gets trimmed)
or youre talking about free blocks? drive maps used/unused blocks on its own
it doesnt need to know how many free blocks are available, it will write to any empty block it finds, if there is none, then it will lookup fo unused blocks (which waits for trim) and use those instead (slow writes, as it has to empty block first ,than do write)
another example of slow writes would be...
TLC memory has 3 bits right...data in one block have 2bits used by some file, 1bit is free...there are few of those blocks aswell (still free space), but to write data on 3rd bit (different file), it will need to wipe whole block and write all 3 bits at once
overprovisioning avoids this
I believe you are correct that deleted data will still remain on the drive until it gets trimmed. That's why I said "the main thing that matters is how much unused space the drive knows
it has." The drive doesn't (presumably) know the space is unused until a TRIM operation has been performed. On a related note, I've always wondered what happens if a drive is completely filled and then partitions are deleted or shrank, leaving unpartitioned (theoretically overprovisioned) space. Without a TRIM operation, how does the controller know that this data can now be safely removed? Unless it is aware of the partition table, I would think it would have to assume the data still needs to be there and would keep bouncing it around, potentially indefinitely. I don't know that the OS would ever inform it because the standard tools Windows (Optimize Drives) and Linux (discard or fstrim) use operate at the filesystem level and unpartitioned space has no filesystem. I think you'd have to go out of your way and use something like blkdiscard, which you'd have to be incredibly careful with.
For the rest, I think you're on the right track but get the details wrong. If you feel like it, look up the difference between cells, pages, blocks, and sectors (LBAs). Programming is relatively fast, especially when less dense (SLC faster than MLC, TLC, QLC). Erasing is slower and has to be done in larger chunks. This is one of the reasons you end up with stale data and need garbage collection.
drives have some degree of overprovisioning. You get a minimum of ~7% simply from the GiB to GB conversion. Many manufacturers go even further. For instance, selling a drive as 240GB or 250GB, instead of 256GB. All of those drives will likely contain 256GiB of NAND. Those drives will have roughly 13%, 9%, or 7% inherent overprovisioning. This space is used for several purposes, including bad block management, wear-leveling, garbage collection, SLC caching, and storing the FTL (Flash Translation Layer). These are all important, which is why SSDs perform better and last longer when the controller has more unused space to work with.
I hope I haven't gotten too far off topic. If so, I apologize.