I followed the directions here for erasing my 500 GB SSD drive on a MacBook Pro:

How to reinstall macOS

I chose the strongest erasing option under the security options. I hit the erase button, and the process took about 3 seconds to complete. I tried again a few times because this seemed way to fast, but got the same result. Is it supposed to be this fast?

  • 2
    Do you want to sell your MBP?
    – klanomath
    Jul 3, 2017 at 23:46
  • That does sound suspiciously short. The normal erase is quite fast since it just marks everything as free space, but actually overwriting the bits should take much longer.
    – JMY1000
    Jul 4, 2017 at 0:04
  • 8
    It's common for SSDs to (transparently) encrypt all data stored on them, using a key stored in a secure area. The erase process (ATA Secure Erase command) then tells the SSD to erase the key, leaving the data unreadable. (If a password is set, the data encryption key is then further encrypted using the password. So you need the password to get the key to get the data. If no password is set, the key is still used internally but it's not obvious to the user that encryption is happening.)
    – Bob
    Jul 4, 2017 at 4:15
  • It's worth considering exactly how secure you need this reformat to be. This approach isn't generally considered secure enough for removing classified data, though it's likely to be plenty sufficient to prevent most from reliably recovering your data.
    – Nat
    Jul 4, 2017 at 4:20
  • @Bob - it's only common on SSDs that are self encrypting. Just this week I took a Windows SSD, mounted it on a FreeBSD machine and was able to read/write without having to decrypt a thing.
    – Allan
    Jul 4, 2017 at 12:58

4 Answers 4


If the drive in question is an SSD then using the 7-pass erase option will not function the same way as on an HDD. On an HDD data is written by using a tiny, and very powerful magnet to flip the magnetic field's direction all over different parts of the disk, and smaller magnetic fields sometimes called "Ghosts" will be left after writing new data to the drive, allowing old data to be recovered by looking at what direction the magnetic field used to flow in. For this reason the 7-pass erase flips the field of the entire drive to the down position (or "0") from beginning to end 7 times in a row, to get rid of any lingering Ghosts. Plus on an HDD files are usually stored as a single stream of data, or in large chunks in only a couple of different places on the drive.

However, and SSD writes data by running a lot of electricity through narrow canals, causing the metal to heat up until the "bit" begins to melt. To stop all this excess heat from killing the drive an SSD writes each file in teeny-tiny chunks, scattered all over different parts of the drive, usually in a very random looking way. Since none of the files are actually intact as a single stream of data the way they are on HDDs, the only thing that allows the computer to figure out what files any of those tiny chunks of data belong to is the Partition Map, which is a record of where on the drive all the parts of a file are.

Basically, when you erase an SSD the only part of the drive that actually gets erased is the Partition Map, because without it to tell the computer where all the different parts of a file are the entire drive looks like a garbled mess of gibberish to the computer. This is why it takes so little time for your drive to secure erase 7 times over, the only part getting erased is that record of where files are, not the files themselves. Since that record is only a few hundred megabytes it only takes about as long to wipe it once as it would to copy a few hundred megabyte large file to another folder.

In the end you should also be careful when using multi-pass erase methods on an SSD, because the excess heat re-writing the same part of the drive that many times creates could be enough to damage it.

  • 6
    Your explanation wouldn't seem to go with the most secure erase option. First, a security researcher would easily be able to piece together the bits of data together by reading the disk raw. You can destroy the HFS+ allocation and catalog, but the bits of information can still be salvaged from the drive. Second, HDD files are very often not able to be written contiguously, either. Third, most SSDs are wiped using TRIM/ATA Enhanced Secure Erase, whose behavior is manufacturer-specific. Some SSDs simply encrypt all information by default, and on a full erase they just throw away the key.
    – oldmud0
    Jul 4, 2017 at 4:29
  • 3
    Probably worth the reading for those who are interested: Reliably Erasing Data From Flash-Based Solid State Drives
    – Num Lock
    Jul 4, 2017 at 6:03
  • 9
    Some parts of this answer are mostly or entirely wrong! 1. Partition Map: from a operating system view the partition map doesn't record the location of files - the allocation bit map, the catalog file etc. do. From the SSD perspective it's a Block Lookup Table (which translates LBA to PBA). 2. "...SSD writes data by running a lot of electricity through narrow canals, causing the metal to heat up until the "bit" begins to melt..." is a over-embellished description of what happens in reality!
    – klanomath
    Jul 4, 2017 at 9:08
  • 7
    when you erase an SSD the only part of the drive that actually gets erased is the Partition Map - This is fundamentally incorrect. From a low level perspective, when a TRIM command is issued to erase a block, it is marked as new and any subsequent read requests return either gibberish or zeros. A partition map is a physical devices logical geometry. A file system has it's own structure for knowing where files are (i.e. FAT = File Allocation Table). As such you can have different file systems on differing partition maps (FAT on GPT or FAT on MBR)
    – Allan
    Jul 4, 2017 at 12:23
  • 4
    Don't forget that the whole "you need to overwrite the disk many times to really secure the wipe" is a misinterpretation of really, really outdated information. Even the guy who wrote the original paper on secure-wiping says it's not necessary. Jul 4, 2017 at 17:04

If the drive is hardware encryped, you can render all content inaccessable just by changing the encryption key on the drive. This would take only seconds.

https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption (see "Disk sanitization" section.)

Note - the data is still there, it is just impossible* to decipher.

* OK, extremely improbable... but that's a cryptography question.


I chose the strongest erasing option under the security options.

If you are erasing an SSD, there's no need to use any software based secure erase methods.

When an ATA Secure Erase (SE) command is issued against a SSD's built-in controller That properly supports it, the SSD controller resets all its storage cells as empty (releasing stored electrons) - just THUS restoring the SSD to factory default settings and write performance. When Implemented properly, SE will process all regions Including the protected storage service regions of the half. 1

In another answer regarding SSD data recovery I write about the different methodologies used to erase data from an SSD. In short, there are two different methods for erasing data from modern SSDs:

  • DRAT - All read commands after an erase command will return the same data
  • RZAT - All read commands after an erase command will return zeros

...if the SSD has only DRAT capability, there is the possibility of recovering data, but it's usually in a situation where you were able to stop the deletion process and immediately start data recovery. If it implement RZAT, you can be pretty sure the recovery will only get zeros back unless they take it (along with a court order) back to the manufacturer to get a low level recovery.

In another answer (SRM gone in macOS Sierra), I detail why srm (secure remove) is no longer an option in Sierra

On an SSD, unlike a HDD, a TRIM command is sent to wipe any data in that marked space. This allows your SSD to be able to write data to that marked space as if it was brand new and never used, and skip the traditional deletion process.

How fast to erase your SSD?

I hit the erase button, and the process took about 3 seconds to complete.... Is it supposed to be this fast?


In a very simplistic way to describe the erase process, when you issue a secure erase command (and your SSD properly implements it), it's not going to write and overwrite each sector as it were magnetic; it's going to "release the stored electrons" (as Kingston describes) and mark the space as "new and ready for use." If it employs RZAT, any read request to an address will return zeros.

I don't know of anyone who has timed the erase process of SSD; normally they test things like iops. However I do know that my 1TB SSD took less than 10 seconds to partition and setup (my first reaction was "damm that was fast"). However, as supporting documentation, from an article on Windows SSD performance2 I was able to grab this little gem:

enter image description here

In the article, they use Linux to force secure erase a 512GB Crucial SSD prior to installing it in a Windows machine; it did it in 9 seconds.


Your erase went fine, it's secure, and you have nothing to worry about that it did it so quickly. A secure erase command marks all data cells as "new, non active" almost instantaneously. Doing multi-pass writes to securely erase data puts undue wear on your SSD while giving you no benefit.

1 Kingston.com: SSD Data Wiping: Sanitize or Secure Erase SSDs?

2 Ultimate Windows SSD Performance Installation Guide


If the SSD secure formatting does not satisfy your confidence, then fall back on the old fashioned way: Fill the drive with other stuff.

The closer this content is to "noise" the better. Compressed content is very close to noise, so any format that uses data compression will be fine - Any of the video formats, JPEG pictures, compressed audio formats, etc.

It doesn't matter if the format is lossless, as long as it is compressed. You can tell a compressed format because if you ZIP it, it doesn't get any smaller.

  • Or just use /dev/urandom
    – Josh
    Jul 21, 2017 at 13:16

You must log in to answer this question.

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