I want to sell my SSD to my friend, it's a 256GB, I have personal stuff on this SSD, so I want to make sure that it will become extremely hard or at least hard to recover the data back. Erasing the whole SSD, as if it were new.

The other questions similar to this one are over-mentioning that:

  1. erasing one partition is useless.
  2. The commands cat, dd, shred are useless.

I read that erasing the SSD is only useful when erasing the whole disk and not only one partition. So I'm asking to make sure if this information is correct and to know how to do it.

So I thought it would be better to create a new thread here for me and for those people who aren't concerned about data losing anything because they only want to get rid of their SSDs in return for money instead of throwing them in the garbage.

  • There's many search results for "secure erase SSD in linux" - and yes, if you think your friend is going to try and recover your personal "stuff" (nudge nudge wink wink) - you'll want to secure erase the SSD
    – Bravo
    Dec 15, 2021 at 7:08
  • Is encrypting the complete SSD an option?
    – user271585
    Dec 15, 2021 at 8:06
  • I don't know from memory what I used years ago, maybe this tool. Good luck. Dec 15, 2021 at 11:59
  • 6
    For ATA (SSD or not), have a look there (hardware/firmware feature-dependent): ata.wiki.kernel.org/index.php/ATA_Secure_Erase
    – A.B
    Dec 15, 2021 at 14:24
  • 1
    – ron
    Dec 15, 2021 at 19:05

3 Answers 3


Useless depends on context. shred can actually be rather useless - when trying to shred a single file, while other copies of the file still exist [every time you click Save, it's another copy] - but there's also the hand sanitizer definition of useless: it kills 99.9% so in practice, it's not useless at all, but people worry about the 0.01% anyway.

For many SSDs, a simple blkdiscard will cause that data to be gone and never to be seen again.

blkdiscard -v /dev/deleteyourssd
# verification:
echo 3 > /proc/sys/vm/drop_caches
cmp /dev/zero /dev/deleteyourssd
# expected result: EOF on /dev/deleteyourssd

If that's not good enough for you, you can use dd or shred to do a random data wipe:

dd bs=1M status=progress if=/dev/urandom of=/dev/deleteyourssd
# or
shred -v -n 1 /dev/deleteyourssd

For verification, the random data wipe needs to be done by encrypting zeroes:

cryptsetup open --type plain --cipher aes-xts-plain64 /dev/deleteyourssd cryptyourssd
# Three unicorns went into a bar and got stuck in the door frame
badblocks -b 4096 -t 0 -s -w -v /dev/mapper/cryptyourssd

You can also run another verification pass after power cycling (for the encryption method it works only if you re-use the same passphrase):

cmp /dev/zero /dev/mapper/cryptyourssd
# expected result: EOF on /dev/mapper/cryptyourssd

Getting data back — after discarding/overwriting and verifying that everything's gone — would require a bit of a miracle and involves corner cases that most users don't really need to concern themselves with.

But if that's still not good enough for you, you can use Secure Erase if the SSD manufacturer provides it for your SSD model, this is described in detail in the ArchLinux wiki:

Just don't mess it up by setting complex ATA password and then locking yourself out, effectively bricking the device. Keep it simple.

Usually with SSDs, it's already quite impossible to restore any data simply after reinstalling Linux, since most flavors mkfs also discard the entire space first thing:

mke2fs 1.46.4 (18-Aug-2021)
Discarding device blocks: done                            
Creating filesystem [...]

In this fashion it's indeed quite useless to erase SSDs yourself, since everything already does that for you without asking, anyway.

And even if that didn't happen, almost every distro sets up fstrim to wipe all free space regularly. Data recovery is a lot less successful on SSDs than on HDDs where you actually have to go out of your way to overwrite free space.

SSDs are so good at discarding all your data in an eyeblink, you should really worry more about losing the data you still need (make backups and backups of your backups), than worry about being unable to erase it.

  • 2
    In a lab environment it's probably possible to restore the contents of an SSD which has only seen blkdiscard since this command does not overwrite memory cells. Dec 15, 2021 at 17:39
  • Most SSD should actually erase their discarded memory cells, as doing so gives a performance benefit, vs. zero benefits in keeping old data around. But yes, blkdiscard/fstrim as well as Secure Erase, depend on implementation details. If you don't trust the hardware then writing random data and verifying its there, is already the best you can do. Dec 15, 2021 at 18:32
  • 1
    the blkdiscard command takes a millisecond to complete - I don't think firmware actually wipes the blocks before they are being reused. Dec 16, 2021 at 9:35
  • It's a background task (and it just doesn't take all that long)... you can check that the SSD no longer returns the data, as for what happens internally it's a black box. Wiping with random data and verifying is much stronger as it gives you formal proof that at least nominal capacity worth of data has been overwritten. As for what is left even then, yes well that's the 0.01% discussion, and perhaps not too relevant for the "sell it to a friend" use case. Dec 16, 2021 at 10:47
  • 2
    100 % - 99.9 % = 0.1 %
    – Arsenal
    Dec 16, 2021 at 12:03
blkdiscard -v -f /dev/nvme0n1 (or /dev/sdX)

Will make your data effectively vanish without any realistic possibility of restoring it.

If you're paranoid, do this:

cat /dev/urandom > /dev/nvme0n1

followed by blkdiscard.

  • 1
    -f (force) seems dangerous - I'd leave that out by default and only add it if needed.
    – EM0
    Aug 2, 2023 at 13:33

The only way to securely erase a NAND Flash drive is to ask the drive controller to do it for you. Host base utilities that use writes will not work. If it's a NVMe drive look up the nvme format command


You must log in to answer this question.

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