Are there any benefits, in terms of performance or security in ‘wiping’ or overwriting an SSD before reinstalling Linux?

No

Security … Depends. If you want to sell the SSD, then yes, wiping the SSD is advised. You don’t need complicated random multiple-write patterns. Just make sure to wipe everything (keywords: wear-leveling, cache), you could use blkdiscard for that.

Performance-wise nothing noticeable would change. Physically, SSDs are fast enough to modify the charge traps to store the bits as needed to store files regardless of what’s in those traps (that’s quite a rabbit hole).

If you plan using the SSD for your own, you don’t need to wipe it, just repartition as needed and create the file systems in the partitions. What I do, is writing some data to the storage to destroy the partition table (dd if=/dev/urandom of=/dev/XYZ where XYZ is my target device – and then leave it runninf for a few seconds).

Since you’re using encryption, the common tools only see garbage and no data (i.e. file system). So simply don’t decrypt and work with the mapped partition but use the device directly.

Not really, unless it was previously used to store unencrypted data.

If you want to destroy old unencrypted data, the fastest way that uses the fewest P/E cycles is to run Secure Erase with hdparm. Many modern SSDs perform hardware encryption, whether you set a password or not. Secure Erase just wipes the encryption key and installs a fresh one. That’s usually good enough for personal use, but it also depends on how well the manufacturer implemented hardware encryption, if at all.

If you want the data gone and don’t trust the manufacturer, the Debian installer offers an option to overwrite free space when setting up partitions. Disclaimer that this would not touch the ~7% hardware-reserved spare blocks that may have been cycled in and out of service.

The following are anecdotal:

• Some SSDs might understand the idea of wiping with zeros and just throw out writes from dd in conjunction with if=/dev/zero, resulting in an apparent, but insecure wipe
• I run wipefs -a /dev/yourDrive on fresh or reused drives to eliminate any potential issues with the remnants of an old partition table. This only erases partition tables, not data blocks.
• A SSD in poor health started throwing errors about bad sectors and stalled the boot process. This was a test rig, so I didn’t really care about data longevity. A full overwrite with dd forced the SSD to retire the bad sectors and gave it a couple more years of useful life.

If you use new encryption and not re-use the existing I’d say there is no advantage in wiping

You only need to overwrite the drive with random data once. Then, as long as every OS install uses FDE, there’s no need to repeat the process.

The reasons why you do the full disk wipe are:

1. To hide the size of the encrypted data by making encrypted data indistinguishable from empty space
2. To erase unencrypted data previously stored on the drive

Both of which only need to be dealt with once, so long as you don’t write unencrypted data to the drive after doing the wipe.

If you are using encryption now, you do not need to wipe the SSD, after a new install the remaining data on the “disk” will still be encrypted, without the key.

I have been using disktest to overwrite my SSD’s.

I overwrite the SSD’s before encryption. works just as well on HDD’s too.

A 2TB HDD takes about 3.5 hours to overwrite with the encrypted seed

A 250GB SSD takes about 17 minutes to overwrite with the encrypted seed

https://crates.io/crates/disktest

https://github.com/mbuesch/disktest

install with cargo

cargo uninstall disktest

much faster than your usual suspects like dd.

it runs as root: so add this $PATH to the root .bashrc export PATH=/root/.cargo/bin:$PATH

recent test run on 250Gb ssd with just write with no verify:

disktest --write -j0 /dev/nvme0n1

The generated --seed is: omNw4JreY1ZVAfwD4dgooF061R10Ra0vnmYv5SrU Use this seed for subsequent --verify.

Writing /dev/nvme0n1 (512 bytes sectors), starting at position 0 bytes… [15:09 / 00h:00m:10s] Wrote 7.62 GiB (8.18 GB) @ 779.3 MiB/s …

[15:26 / 00h:17m:16s] Done. Wrote 238.47 GiB (256.06 GB, 256059113472 bytes) @ 235.5 MiB/s. Successfully dropped file caches. Generated --seed omNw4JreY1ZVAfwD4dgooF061R10Ra0vnmYv5SrU

Success!

to check my SSD’s I use:

prometheus-smartctl-exporter

sudo smartctl -i -a /dev/nvme0n1

AFAIK it’s a bad idea to use dd or another wiping tool that just overwrites the logical partitions on flash based media, and is also not that effective for security. SSDs have wear leveling and what the computer sees does not map 1 to 1 to what’s actually on the flash chips. They also have extra overprovisioned space inaccessible to your computer specifically for shuffling data around when wear leveling. So not only are you wasting write cycles, it’s not guaranteed to actually overwrite all your data on the flash chips themselves.

If you want to wipe an SSD, use secure erase from a tool like nvme-cli which will directly tell the controller to erase all the data. How well the controller implements that is anyone’s guess though.

I’d say if you’re going to the effort of fully encrypting your new install, doing a secure erase will be in that spirit and won’t hurt. There won’t be any performance benefit but it will (probably) ensure that none of your previous unencrypted data is still there, though even if you don’t do this, just writing to the drive in normal use will eventually fill up the free space and make it less and less likely that sensitive information is recoverable, but how long this happens depends on how you use the computer.

Maybe. Some people have used SpinRite 6.1 to rewrite every sector, and that’s improved performance on some SSD’s. It rewrites each sector and restores the cell’s charge. That’s great if you need the data on there now.

Now, if you’re erasing the disk (by any means, including just a quick format C:), any sectors you use will be written with new data, so that shouldn’t matter.

Just erase the disk (securely, if you want) and get going, and it should be fine.