I want to reset the performance of the SSD to its out-of-box performance. And I found after using these commands shown in the title, the performance may or may not reset.

before any trim operations, run:

fio --filename=/dev/nvme1n1 --direct=1 --rw=write --bs=4k --size=5G --numjobs=16 --iodepth=32 --group_reporting --name=test

on Samsung NVMe 980 pro 500G shows that the bandwidth is ~1100MB/s, and Then I trim the device to regain performance:

  • command A used: nvme format -s1 /dev/nvme1n1
    • Result: running the fio command above shows that bandwidth is STILL ~1100MB/s
  • command B used: fstrim -v /mnt/mount-point-of-nvme1n1p1
    • Result: running the fio command above shows that bandwidth improves to ~1800MB/s

I know that nvme format -s1 and hdparm --security-erase are low-level erase operation that erase all data from the device (nvme and sata respectively), while fstrim reserves user data. The data is 30% full in this ssd. So one reason may because these 30%-full-data is badly layout in the device, making the performance does not regained after a trim operation? What may be missed by fstrim here?


1 Answer 1


With certain commands you are saying "this area is empty but erase it at your leisure" which means it can do so over time and even stop when it considers it has enough for the time being. With other commands you are saying "make all of this area empty and don't return control back to me until you've actually erased all of it". fstrim is like the former. hdparm --security-erase is like the later and will lead to more consistent Out Of the Box (OOB)/Fresh Out of the Box (FOB) performance benchmarking. An additional difference is that the hdparm --security-erase/nvme format commands will be able to erase blocks that aren't currently "reachable" for some reason (e.g. because of internal over provisioning). It is important to know whether the command will return before all the work is done though - if it just erases the Flash Translation Layer then the data is irrecoverable but the cells have not actually been pre-cleared...

The difference turns up if you consistently write non-stop at top speeds for a long period of time when the drive was previously "full". The point at which performance falls will likely be earlier with fstrim-like techniques because you can run out of pre-erased blocks sooner. Additionally, properly erasing all the cells of a drive will obviously cut a piece of its lifespan away too.

(Also looking at the fio command line you gave, it's a pity you didn't use one of the faster asynchronous fio ioengines... Your iodepth setting is likely meaningless given the default ioengine :-( )


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .