There is a difference between wiping the FTL and actually erasing the NAND.
In the article you linked to, you can see HDtune screenshots where TRIMing or secure erasing would lead to different benchmark scores. The only reason for this is because if you read data from an SSD which the SSD knows is not in use, it won't even try to read from the NAND.
If you buy a new unused SSD, its FTL (Flash Translation Layer) will be empty. This means that any read request you perform will not actually read from NAND, but rather return zeroes.
This is a crucial difference between modern SSDs and harddrives. A harddrive cannot know whether a certain block of data is actually in use or not - only the small DRAM cache can do that which is severely limited in size. Opposite to this, SSDs use a FTL mapping table that is stored in DRAM that allows the SSD controller to know which blocks are in use.
The result is that, if you perform a HDtune benchmark, you can see very easily which LBA spots contain valid data, and which spots do not. Any block requested by the host that is not included in the FTL, means the SSD doesn't even have to try to read from NAND. It also wouldn't know where to read from; since SSDs do not have 1:1 logical LBA versus physical LBA like harddrives do.
In HDtune benchmark, you can see the throughput graph fluctuating. If you perform overprovisioning, you will see this portion having a very solid high performance horizontal line while other spots show wildly fluctuating throughput. In addition, random seeks can be separated into two lines: the upper (slower) line are seeks to LBA spots which contain valid data, while the lower (faster) line are seeks to LBA spots which do not exist in the FTL table. This is much faster because you are only communicating with the controller itself; not the NAND.
You can TRIM all LBA space in one second, but that doesn't mean the NAND get erased. Instead, all that happens is that the FTL is updated to reflect the new state of 'claimed sectors' which the SSD has to remember. All the other sectors, the SSD can do to it what it wants. Depending on the implementation of garbage collection (GC) with either agressive/background GC (Samsung) or lazy/foreground GC (Intel) this will lead to the periodic erasing and reallocation of TRIMed space.
So to make things simple, the controller simply knows which spots have been written to, and won't even try to read from NAND in cases where it knows the data has to be zeroes - either because the SSD is brand new and that spot never has been written to, or because that spot has been TRIMed in the past. Regardless of whether GC succeeded, the controller will return zeroes without even reading from the NAND.
As for erasing all NAND at once; you should be able to disqualify this theory by looking at power consumption. SSDs use the most power when erasing NAND. If you do this in all NAND chips, this ought to be very noticeable since nothing will lead to a higher power consumption than something like this.
What actually happens is that the garbage collection which runs periodically (aggressive GC) will scan for unused portions and erase these in background so that these NAND pages are ready for reprogramming with new data. This does not happen when you TRIM certain LBA or even all LBA space.
Facebook
Twitter