Trimming sectors basically says to the SSD that the sectors do no longer contain useful data, and can be garbage collected (i.e. erased) so that they can be re-used for future write operations. This can improve write performance when the disk is getting full, since the firmware translation layer of the SSD controller has more "leeway" to play with physical blocks/pages.
hdparm, sectors to be trimmed are provided as LBA (logical blocks). If your SSD has been formatted with a filesystem, trimming LBA will certainly corrupt the filesystem and make it unusable (since a user has no knowledge of the underlying filesystem-to-LBA mapping). For SSD formatted with a filesystem, trimming should be done at a higher level, with tools such as
When supported, the "ATA secure erase" command should erase all the physical blocks of the SSD. It could be roughly equivalent to trimming all the sectors of the SSD, but probably in a more optimized and secure way.
The referenced link indicates that the "secure erase" command failed when used with an USB-to-SATA adapter. This could be due to a poor or buggy implementation of the USB-to-SATA controller, or an implementation which does not comply with recent SATA specifications.
To wipeout the contents of a SSD, the SATA secure erase command is the preferred way to go. The
--trim-sector-ranges option of a hdparm is for experimental and benchmark purpose. Only for very specific applications (some database systems) that addresses SSD at the LBA level can trimming sectors with
hdparm make sense.
To finish, the recommendation of leaving some unpartioned space (called over-provisioning) for wear-levelling is interesting, provided this space has been trimmed in some way before (an "ATA secure erase" will also do for this purpose). If it's not the case, and if previous data were to exist in the LBA range of the unpartioned space, the SSD controller will assume it is still valid data and strive to keep it "alive", by possibly moving the associated blocks and pages (thus increasing overall wear!)