Difference between revisions of "SSD memory cell clearing"

From ArchWiki
Jump to: navigation, search
m (Step 1 - Make sure the drive security is not frozen)
m (tl; dr)
(36 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
[[Category:Storage]]
 
[[Category:Storage]]
{{i18n|SSD Memory Cell Clearing}}
 
 
{{Article summary start}}
 
{{Article summary start}}
 
{{Article summary text|This article presents a method to reset all cells on an SSD to their factory default state thus recovering any loss of write performance.}}
 
{{Article summary text|This article presents a method to reset all cells on an SSD to their factory default state thus recovering any loss of write performance.}}
Line 10: Line 9:
 
== Introduction ==
 
== Introduction ==
  
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.
+
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!}}
+
  
== Quick N' Dirty ==
+
{{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|It is recommended that you read the rest of the article BEFORE you try this!}}
+
{{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 ==
 +
 +
{{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-set-pass Eins /dev/sdX
 
  hdparm --user-master u --security-erase Eins /dev/sdX
 
  hdparm --user-master u --security-erase Eins /dev/sdX
Line 24: Line 26:
 
  # hdparm -I /dev/sdX
 
  # hdparm -I /dev/sdX
  
If the command output shows "frozen" one cannot continue to the next step. Most BIOSes block (do no allow) the ATA Secure Erase command by issuing a "SECURITY FREEZE" command to "freeze" the drive before booting an operating system.
+
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)pluging 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.
+
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."
+
* 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) 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], see the grml2ram option. Run ''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, 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.
* 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:
  
 
<pre>Security:  
 
<pre>Security:  
Line 44: Line 46:
  
 
== Step 2 - Enable security by setting a user password ==
 
== Step 2 - Enable security by setting a user 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).}}
+
{{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 "Eins" as shown:
 
  # hdparm --user-master u --security-set-pass Eins /dev/sdX
 
  # hdparm --user-master u --security-set-pass Eins /dev/sdX
 
  security_password="Eins"
 
  security_password="Eins"
Line 70: Line 72:
 
== Step 3 - Issue the ATA Secure Erase command ==
 
== Step 3 - Issue the ATA Secure Erase command ==
  
# time hdparm --user-master u --security-erase Eins /dev/sdX
+
{{warning|Triple check that the correct drive designation is used. '''THERE IS NO TURNING BACK ONCE THE ENTER KEY HAS BEEN PRESSED!''' You have been warned.}}
  
Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD, for a 1TB hard disk it might take 3 hours or more!
+
# hdparm --user-master u --security-erase Eins /dev/sdX
 +
 
 +
Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD.
  
 
  security_password="Eins"
 
  security_password="Eins"
Line 79: Line 83:
 
  0.000u 0.000s 0:39.71 0.0%      0+0k 0+0io 0pf+0w
 
  0.000u 0.000s 0:39.71 0.0%      0+0k 0+0io 0pf+0w
  
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:
+
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:
 
  # hdparm -I /dev/sdX
 
  # hdparm -I /dev/sdX
  
Line 93: Line 97:
 
         2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.</pre>
 
         2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.</pre>
  
== Post Process Observation ==
+
== Tips ==
 
+
See the [[GRUB_EFI_Examples]] for hardware-specific instructions to get GRUB EFI working following a wipe.
{{Note|Once switching from an MBR to GPT partition scheme, this is a non-issue.}}
+
 
+
I experienced a "glitch" with my Intel X25-M (G2) after doing this procedure.  I do not know if it's fdisk's fault or the procedure's fault.
+
 
+
For some reason, after creating two partitions (1st = 68 G and 2nd = rest of drive), the 32 H and 32 S settings weren't retained.  Creating just one partition, writing changes, and exiting gave a result consistent with the -H 32 -S 32 settings when checking via the "fdisk -l" command.  However, after adding the 2nd partition, writing and running the same "fdisk -l" command, new values for the geometry were shown - they switched to 255/63!  The solution was to start fdisk with the 32/32 parameters and write down the number of cylinders, then use cfdisk to do my partitioning.
+
 
+
Example:
+
 
+
# fdisk -H 32 -S 32 /dev/sdb
+
+
Command (m for help): p
+
+
Disk /dev/sdb: 80.0 GB, 80026361856 bytes
+
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors
+
Units = sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disk identifier: 0x00000000
+
 
+
Device Boot      Start        End      Blocks  Id  System
+
/dev/sdb1              32  132812799    66406384  83  Linux
+
/dev/sdb2      132812800  156301311    11744256  83  Linux
+
 
+
Here the correct number of cylinders is 152638.  I now went into cfdisk and invoked the "geometry" option via: {{Keypress|g}}.  I then manually defined the number of heads to 32, sectors per track to 32, and cylinders to 152638.  Now I setup my partitions:
+
 
+
<pre>                                    cfdisk (util-linux-ng 2.18)
+
 
+
                                          Disk Drive: /dev/sdb
+
                                    Size: 80026361856 bytes, 80.0 GB
+
                          Heads: 32  Sectors per Track: 32  Cylinders: 152638
+
 
+
    Name            Flags        Part Type    FS Type              [Label]            Size (MB)
+
-------------------------------------------------------------------------------------------------------
+
    sdb1                          Primary      ext4                                      68000.16   
+
    sdb2                          Primary      ext4                                      12026.12</pre>
+
 
+
Now querying the device via fdisk gave the consistent values.
+
 
+
# fdisk -l /dev/sdb
+
 
+
Disk /dev/sdb: 80.0 GB, 80026361856 bytes
+
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors
+
Units = sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disk identifier: 0x00000000
+
 
+
  Device Boot      Start        End      Blocks  Id  System
+
/dev/sdb1              32  132812799    66406384  83  Linux
+
/dev/sdb2      132812800  156301311    11744256  83  Linux
+

Revision as of 00:48, 1 April 2013

Summary help replacing me
This article presents a method to reset all cells on an SSD to their factory default state thus recovering any loss of write performance.
Related Articles
Solid State Drives
Securely Wipe HDD

Introduction

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 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!
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

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

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, 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 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.
  • Make sure drive security is disabled in BIOS, so no password is set:
Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

Step 2 - Enable security by setting a user 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:

# hdparm --user-master u --security-set-pass Eins /dev/sdX
security_password="Eins"
/dev/sdX:
Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high

As a sanity check, issue the following command

# hdparm -I /dev/sdX

The command output should display "enabled":

 Security: 
        Master password revision code = 65534
                supported
                enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        Security level high
        2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

Step 3 - Issue the ATA Secure Erase command

Warning: Triple check that the correct drive designation is used. THERE IS NO TURNING BACK ONCE THE ENTER KEY HAS BEEN PRESSED! You have been warned.
# hdparm --user-master u --security-erase Eins /dev/sdX

Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD.

security_password="Eins"
/dev/sdX:
Issuing SECURITY_ERASE command, password="Eins", user=user
0.000u 0.000s 0:39.71 0.0%      0+0k 0+0io 0pf+0w

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:

# hdparm -I /dev/sdX

The command output should display "not enabled":

 Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

Tips

See the GRUB_EFI_Examples for hardware-specific instructions to get GRUB EFI working following a wipe.