Is shred bad for erasing SSDs

Writing a block to an SSD does not overwrite the old block. That's because all recent SSDs use something called "wear leveling".

To write a block to an SSD, you need to erase it first, and then you can write the new data. But erasing is an operation that can only be executed a limited number of times; each time you do an erase, you "weaken" the hardware, until the block cannot be properly erased anymore.

So instead of erasing and overwriting the same block, wear leveling will make the SSD pick a different, unused block, and will write to this block, leaving the data on the old block in place.

And if the data on the old block is in place, that means it still can be read.

So any of the commands you can use to "overwrite" a file (cp, dd, cat, shred, and many more) have this weakness: It does not actually overwrite the file at all, instead it writes zeroes, random data or whatever to new blocks.

So unlike for HDs, this is not a good way to make sure your data is gone, and cannot be read by someone else.

All of those commands are "bad" for the SSD in the sense that any writes use up the limited number of writes an SSD has, decreasing the lifetime of the SSD. And shred is particularly bad, because it overwrites the file repeatedly. On an HD, this serves a purpose: The read-write-head is never completely centered, so overwriting it multiple time makes sure (or tries to make sure) there's no residual magnetic data left at the border of the track that could be used by the knowledgeable to reconstruct the data.

As for blkdiscard, this calls fstrim, which uses ATAPI trim bit to tell the drive that the block is no longer needed. You can find more details in the ACS-4 specification.

But again, this is not safe: It only tells the SSD to put this block on the list of blocks that are empty and can be re-used. The SSD can choose to actually erase this block right now, or at some time when it is idle, or even just right before the next write to this block. So this isn't a safe way to make sure your data is gone, either.

The reason TRIM was introduced was that the SSD had no way of figuring out if a block with data was still used by the filesystem or not. Which means that even the filesystem had stopped using it, it couldn't be added to the pool that was getting used for wear leveling. TRIM was never meant as a safe way to erase blocks.

As has been mentioned in the comments, there is a way to securely erase the complete SSD. However, if you only want to securely erase a single file, that's probably not what you want.

So what's the solution for your use case? If it is really

I'm not dealing with sensitive data here and don't need to protect the drive from a knowledgeable person going to great length to recover data

then you can just use rm. It actually takes quite a bit of knowledge and effort to recover a deleted file on an ext4 file system, in particular if more writes have happened to this file system in the meantime. It's doable, but not by anyone. And it's certainly the fastest variant.

The next best one is blkdiscard (which will only work on SSD that support TRIM, but that should be true for modern SSDs). While this won't make it safe, as described above, now the bar has been raised to someone who can access the SSD directly. Which no one without the special hardware needed to do this can.

Overwriting the file by whatever means is still the worst: The bar to reconstruction is the same as above, but you've decreased the lifetime of your SSD by doing it, and it will also take longer, no matter which command you use.