On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were manufactured, thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

−

== Introduction ==

+

{{Warning|Back up ALL data of importance prior to continuing! Using this procedure will destroy ALL data on the SSD and render it unrecoverable by even data recovery services! Users will have to repartition the device and restore the data after completing this procedure!}}

−

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were manufactured, thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

−

{{Warning|Back up ALL data of importance prior to continuing! Using this procedure will destroy ALL data on the SSD and render it unrecoverable by even data recovery services! Users will have to repartition the device and restore the data after completing this procedure!}}

−

{{Note|There is no need to zero out the drive using dd. Doing so will only cause more wear of the SSD and reduce its lifespan. Simply issuing a Secure Erase command will also ensure that the data is [https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase permanently erased].}}

{{Warning|Do '''not''' proceed with this if your drive isn't connected directly to a SATA interface. Issuing the Secure Erase command on a drive connected via USB or a SAS/RAID card could potentially brick the drive!}}

{{Warning|Do '''not''' proceed with this if your drive isn't connected directly to a SATA interface. Issuing the Secure Erase command on a drive connected via USB or a SAS/RAID card could potentially brick the drive!}}

== tl; dr ==

== tl; dr ==

+

{{Warning|It is recommended that you read the rest of the article BEFORE you try this! This section literally shows the minimum to wipe out an entire SSD for those not wanting to scroll though the text.}}

+

hdparm --user-master u --security-set-pass PasSWorD /dev/sdX

+

hdparm --user-master u --security-erase PasSWorD /dev/sdX

−

{{Warning|It is recommended that you read the rest of the article BEFORE you try this!}}

−

−

hdparm --user-master u --security-set-pass Eins /dev/sdX

−

hdparm --user-master u --security-erase Eins /dev/sdX

== Step 1 - Make sure the drive security is not frozen ==

== Step 1 - Make sure the drive security is not frozen ==

Line 30:

Line 27:

* It has been reported that hooking up the drive to an eSATA SIIG ExpressCard/54 with an eSATA enclosure will leave the drive security state to "not frozen".

* It has been reported that hooking up the drive to an eSATA SIIG ExpressCard/54 with an eSATA enclosure will leave the drive security state to "not frozen".

−

* Placing the target system into "sleep" (Clevo M865TU notebook, Fujitsu T2010 notebook, Dell XPS M1330, Lenovo ThinkPad x220/x230, Samsung NC10) and waking it up again has been reported to work as well; this may reset drives to "not frozen". In case you are booting from USB, you need a distribution, that runs entirely in RAM, like [http://grml.org Grml], see the {{ic|grml2ram}} option. Run {{ic|echo -n mem > /sys/power/state}} to set the computer to sleep.

+

* Placing the target system into "sleep" (Clevo M865TU notebook, Fujitsu T2010 notebook, Dell XPS M1330, Lenovo ThinkPad x220/x230/T420, Samsung NC10, Samsung Ultrabook 530U3C) and waking it up again has been reported to work as well; this may reset drives to "not frozen". In case you are booting from USB, you need a distribution, that runs entirely in RAM, like [http://grml.org Grml], see the {{ic|grml2ram}} option. Run {{ic|echo -n mem > /sys/power/state}} to set the computer to sleep.

* Hooking up the drive to a USB 2/3 port does '''NOT''' work, as you need to issue IDE commands, which is only possible via IDE/SATA connection.

* Hooking up the drive to a USB 2/3 port does '''NOT''' work, as you need to issue IDE commands, which is only possible via IDE/SATA connection.

* Make sure drive security is '''disabled''' in BIOS, so no password is set:

* Make sure drive security is '''disabled''' in BIOS, so no password is set:

Line 47:

Line 44:

{{Note|When the user password is set the drive will be locked after next power cycle denying normal access until unlocked with the correct password.}}

{{Note|When the user password is set the drive will be locked after next power cycle denying normal access until unlocked with the correct password.}}

−

Any password will do, as this should only be temporary. After the secure erase the password will be set back to NULL. In this example, the password is "Eins" as shown:

+

Any password will do, as this should only be temporary. After the secure erase the password will be set back to NULL. In this example, the password is "PasSWorD" as shown:

Warning: Back up ALL data of importance prior to continuing! Using this procedure will destroy ALL data on the SSD and render it unrecoverable by even data recovery services! Users will have to repartition the device and restore the data after completing this procedure!

Warning: Do not proceed with this if your drive isn't connected directly to a SATA interface. Issuing the Secure Erase command on a drive connected via USB or a SAS/RAID card could potentially brick the drive!

Contents

tl; dr

Warning: It is recommended that you read the rest of the article BEFORE you try this! This section literally shows the minimum to wipe out an entire SSD for those not wanting to scroll though the text.

Step 1 - Make sure the drive security is not frozen

Issue the following command:

# hdparm -I /dev/sdX

If the command output shows "frozen" one cannot continue to the next step. Most BIOSes block the ATA Secure Erase command by issuing a "SECURITY FREEZE" command to "freeze" the drive before booting an operating system.

A possible solution for SATA drives is hot-(re)plug the data cable (which might crash the kernel). If hot-(re)plugging the SATA data cable crashes the kernel try letting the operating system fully boot up, then quickly hot-(re)plug both the SATA power and data cables.

It has been reported that hooking up the drive to an eSATA SIIG ExpressCard/54 with an eSATA enclosure will leave the drive security state to "not frozen".

Placing the target system into "sleep" (Clevo M865TU notebook, Fujitsu T2010 notebook, Dell XPS M1330, Lenovo ThinkPad x220/x230/T420, Samsung NC10, Samsung Ultrabook 530U3C) and waking it up again has been reported to work as well; this may reset drives to "not frozen". In case you are booting from USB, you need a distribution, that runs entirely in RAM, like Grml, see the grml2ram option. Run echo -n mem > /sys/power/state to set the computer to sleep.

Hooking up the drive to a USB 2/3 port does NOT work, as you need to issue IDE commands, which is only possible via IDE/SATA connection.

The drive is now erased. After a successful erasure the drive security should automatically be set to disabled (thus no longer requiring a password for access). Verify this by running the following command: