I recently came across an interesting quirk that I had tasked myself with investigating and figuring out. I had a couple older model Samsung SSD’s which, ran in conjunction with a PERC H730 controller. Unfortunately, as soon as the 1GB controller cache was full, they tumbled from their 500 MB/s design limitation (SATA-3, 6 Gbps) down to something like 30-40 MB/s, which is a horrible performance value for that hardware.
Unaware of the actual reason for this, I started to poke around in the controller, switching between RAID and non-RAID (HBA-mode), retesting, and turning the controller cache on and off. But nothing really helped; they remained slow.
As part of poking around I they tried a ATA Secure Erase procedure on one of the disks. The procedure requires 2-3 commands and is described excellently in the Thomas Krenn-Wiki.
Result
Full speed. The SSD recovered its full writing speed.
Reason
The Secure Erase procedure did something only it itself can do, or TRIM. My assumption is that the used SSD in its previous RAID configuration with the PERC H730 was unable to receive TRIM commands from the operating system due to the controller simply being unable to pass them through.
After switching the controller to actual HBA mode, where there is direct access to the disks, TRIM commands would also get passed through. I just never had written and then deleted enough data on a “discard”-enabled filesystem to give the SSD’s internal flash structure enough space to efficiently write data again without intense write amplification (I linked the Wikipedia article here, because it explains the actual workings of write amplification very well).
Summary
Short, as a mnemonic: ATA Secure Erase resets the SSD’s flash translation layer and marks all NAND blocks as erased, restoring clean free space. This eliminates stale, fragmented data and reduces the extra copying and garbage collection that caused write amplification when TRIM wasn’t running.
And why does a simple overwriting of data, say with dd, not work: dd overwrites logical sectors, but the SSD’s controller may write to new physical NAND pages, leaving old pages invalid but not erased. Without TRIM, the SSD may still lack accurate knowledge of which data is disposable.
In general:
- when using SSD’s make sure they run on a controller that can support TRIM
- when beyond possibilities with TRIM, do a ATA Secure Erase
- check your write speeds before placing and OS or data on such SSD’s, it will save you a lot of time
Leave a Reply