Robert, did you know when everyone thought Donald Trump said he wanted to make America great again... they misunderstood what his real speech was as written! It was not GREAT it was GRATE as in the finger nails tracking across a blackboard makes your teeth grate ... again.

Zarf, technically with modern TRIM aware SSD drives connected by a TRIM command compatible interface (NOT USB to SATA bridged drive enclosure) and running under a TRIM compatible operating system that deallocates logical sectors in realtime flagging them for erasure and that any subsiquent reads from that logical sector should return a zerod sector... then simply deleting the file itself *should* cause those flash cells to become unreadable as they are erased either imediatly or in pretty short order. Also if you had written to that file after its original creation then the logical sectors data is read out to a cache, that selection of flash cells flagged as ready for erasure at next garbage collection event and the new data merged as necesary with the cached data and then written to a previously erased set of flash memory cells in the write leveling list and mapped into the original file. So in theory those data snippets shunted around the flash memory cells will be erased in the background so there is no practical need to erase properly implemented TRIM + wear leveling and garbage collection. At worst forcing a garbage collection after a TRIM is all that is necesary to ensure a clean up all deleted and TRIM'd files.

Zarf, BTW the way to read the free pool of flash memory cells in a SSD is to remove the flash memory chips and read them directly in a test rig... or protyping rig. Not a big challenge. BUT as I said recycling of those demapped cells on overwrite wear leveling is an ongoing background firmware erase process and the previous cells data is gone fairly promptly without any extra erase utility intervention.

TK, I agree that TRIM can eradicate your data but I don't believe it can be counted on 100% of the time. I apologize I'm only familiar with Sandforce/DuraWrite TRIM, but have seen different SSD manufacturers implement it with foreground garbage collection instead of background which could leave your old data flagged for reflashing around for a very long time - especially on a somewhat empty drive.

Like you said, TRIM is not passed along on most USB connected SSDs. It is also not used on most older RAID configurations. This product has one function, to permanently erase data and publisher's product page states that there is "No Chance of Data Recovery" and I'd just like to know in broad terms how they can accomplish it.

Zarf, quite right regarding TRIM.. it cannot be counted on blindly, one should test it for any given SSD firmware, and learn the garbage collection protocol used by any given SSD manuafacturer and drive.

The problem of hardware raid controllers is the TRIM command is not RAID aware and RAID controllers do not expose the individual component drives logical block Access number to the operating system so if the OS dried to de-allocate / TRIM a hardware raided array the RAID controller would have to re-map the systems TRIM request to the specific drives that relates to and not many if any controller makers have built in that functionality probably because there is no existing standard to do it across the many RAID configurations and Drive types that can make them. Techncally it could be done using the SCSI hardware/firmware model as that has a de-allocate command built into the command set but everything on the OS side has to support it as well. As could the USB to SATA bridge that emulates a USB SCSI device it could theoretically re-map SCSI de-allocate to SATA TRIM commands as both are moderatly well defined but requires smarter bridging chipsets than are currently used.

In broad or specific terms we have never had a direct response from this vendor in comments here to any technical queries or challenges to this vendors claims or dubious activities see MikeR's comment today...

Technically IF the garbage collection mechanisim is reliable and known when it operates, i.e. at device boot up or can be triggered by a manufacturer specific ATA-API command then simply overwriting the data to be erased with one pass of zeros will move the previous datas flash memory cells into the garbage pool of cells which will get ereased formally by the firmware during the next garbage collection cycle. Just need to ensure that cycle runs and completes and the data is gone perminantly even from NCIS geeks. So the secret is know your SSD well and you can be assured of your data's security especially if you use hardware encryption too.