said by Camelot One:
I use KillDisk for Windows. It takes awhile, because unlike an SSD Secure Erase, it writes 0s to every block on the drive. But that guarantees nothing is recoverable.
This also has some dire consequences performance-wise, as the FTL map becomes completely full. The end result is that the drive's GC has to try and figure out which LBAs are no longer used. When GC kicks in, all ATA CDBs are suspended (meaning the OS/controller submits a CDB and the drive sits there blocking/waiting on it, since internally the SSD firmware GC is busy reaping pages). In some cases this can take so long that the OS, driver, or controller itself will actually report a drive timeout (I can provide evidence of this if need be). This will continue to happen until the FTL map can be cleared. AFAIK, KillDisk doesn't go back later and issue TRIM requests for the entire LBA range of the drive (0 to max), so the FTL ends up being full, resulting in abysmal performance compared to out-of-the-box.
If anyone considers using this method, I would strongly suggest doing the full LBA erase first, followed immediately by a Secure Erase (which is the only thing that clears the FTL map).
Overall I don't think the paranoia behind writing zeros to every LBA on an SSD is justified. The percentage of the population who are going to open up an SSD and de-solder each NAND flash chip and drop them onto a flash dumper board, just to get your data = probably 0.001%.--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.