Arch Linux

jbrind

Member

Registered: 2013-09-18

Posts: 3

SSD Secure Erase Fails

Hi,

After several years of use I thought the SSD in my Asus EeePC 1000 could benefit from a cell reset as described below:

https://wiki.archlinux.org/index.php/SS … l_Clearing
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

I ran the following commands using a recent copy of Arch off a USB stick. 

# hdparm -V

hdparm v9.43

# hdparm -iI /dev/sda


/dev/sda:

 Model=ASUS-PHISON SSD, FwRev=TST2.04U, SerialNo=SOQ1881040
 Config={ HardSect NotMFM Fixed DTR>10Mbs }
 RawCHS=15636/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
 BuffType=DualPort, BuffSize=1kB, MaxMultSect=1, MultSect=off
 CurCHS=15636/16/63, CurSects=15761088, LBA=yes, LBAsects=15761088
 IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 *udma4 
 AdvancedPM=no
 Drive conforms to: Unspecified:  ATA/ATAPI-4,5

 * signifies the current active mode


CompactFlash ATA device
	Model Number:       ASUS-PHISON SSD                         
	Serial Number:      SOQ1881040          
	Firmware Revision:  TST2.04U
Standards:
	Supported: 5 4 
	Likely used: 6
Configuration:
	Logical		max	current
	cylinders	15636	15636
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   15761088
	LBA    user addressable sectors:   15761088
	Logical/Physical Sector size:           512 bytes
	device size with M = 1024*1024:        7695 MBytes
	device size with M = 1000*1000:        8069 MBytes (8 GB)
	cache/buffer size  = 1 KBytes (type=DualPort)
Capabilities:
	LBA, IORDY(cannot be disabled)
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 1	Current = 0
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	Power Management feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	CFA feature set
	   *	Mandatory FLUSH_CACHE
	   *	CFA advanced modes: pio5 pio6 mdma3 mdma4 
Integrity word not set (found 0x0000, expected 0x15a5)                                                                                 

No 'Security' information is displayed, only an 'Integrity word not set' error. When I proceed to set a password and erase as per the instructions, the commands fail with an input/output error:

# hdparm --user-master u --security-set-pass pw /dev/sda

security_password="pw"

/dev/sda:
 Issuing SECURITY_SET_PASS command, password="pw", user=user, mode=high
SECURITY_SET_PASS: Input/output error                                                                                                                          
 
# hdparm --user-master u --security-erase pw /dev/sda

security_password="pw"

/dev/sda:
 Issuing SECURITY_ERASE command, password="pw", user=user
ERASE_PREPARE: Input/output error

At least one person has the exact same problem:

http://forums.gentoo.org/viewtopic-t-84 … art-0.html

Is this a limitation of my SSD? I'd appreciate any advice on workarounds.

Thanks.

Last edited by jbrind (2013-09-19 20:49:06)

karol

Archivist

Registered: 2009-05-06

Posts: 25,440

Re: SSD Secure Erase Fails

Hi, jbrind, and welcome to Arch Linux forums :0(

When pasting configs, code or command output, please use [ code ] tags https://bbs.archlinux.org/help.php#bbcode

like this

It makes the code more readable and - in case of longer listings - more convenient to scroll through.

Googling 'ERASE_PREPARE: Input/output error' didn't help much, I found https://github.com/marktheunissen/wiki/wiki/Intel-ssd and http://forums.partedmagic.com/viewtopic … f&start=10 - no solutions.

In the  marktheunissen wiki the author wrote that executing security erase without setting a password result in the error you get:

Some variations of this method are spread on various internet sites, but they will not work because security is “not enabled”, when issuing the hdparm command:

sudo hdparm --user-master u --security-erase NULL /dev/sda

As you can see, this results to the following output/error:

security_password=""

/dev/sda: Issuing SECURITY_ERASE command, password="", user=user ERASE_PREPARE: Input/output error

Maybe it's too short, maybe it's just a coincidence that you get this error - I don't know.

Last edited by karol (2013-09-18 18:31:45)

jbrind

Member

Registered: 2013-09-18

Posts: 3

Re: SSD Secure Erase Fails

Hi, jbrind, and welcome to Arch Linux forums :0(

When pasting configs, code or command output, please use [ code ] tags https://bbs.archlinux.org/help.php#bbcode

like this

It makes the code more readable and - in case of longer listings - more convenient to scroll through.

Googling 'ERASE_PREPARE: Input/output error' didn't help much, I found https://github.com/marktheunissen/wiki/wiki/Intel-ssd and http://forums.partedmagic.com/viewtopic … f&start=10 - no solutions.

In the  marktheunissen wiki the author wrote that executing security erase without setting a password result in the error you get:

Some variations of this method are spread on various internet sites, but they will not work because security is “not enabled”, when issuing the hdparm command:

sudo hdparm --user-master u --security-erase NULL /dev/sda

As you can see, this results to the following output/error:

security_password=""

/dev/sda: Issuing SECURITY_ERASE command, password="", user=user ERASE_PREPARE: Input/output error

Maybe it's too short, maybe it's just a coincidence that you get this error - I don't know.

Thanks for your reply. I didn't remember code tags existed - I've fixed that.

I've tried setting various lengths of password as well as 'NULL' but no joy.

The link below suggests that old SSDs such as the one in the EeePC 900, a similar model to mine, do not support this ATA command at all. As far as I'm aware the same SSD is used in both, should I give up hope in restoring my factory write speeds? As I understand it the reset must be performed at the hardware level to accomplish this.

http://thelastmaimou.wordpress.com/2013 … -only-one/

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,429

Re: SSD Secure Erase Fails

I don't have personal experience with those SSD models, but to my understanding you are right (i.e. you cannot use secure erase). 

OTOH the secure erase ATA funtion mainly serves the purpose to safely wipe the whole drive (incl. cache area) from data. The so-called 'cell-clearing' for SSDs is just a side effect, as I understand it. The ATA security commands existed in HDDs before there were SSDs and particularly the early SSD models all had big curves to get the firmware right. Some vendors offered DOS tools (as mentioned in the article too). Maybe you find something like that with asus (I would not bet on it).

The link you post has good explanations, but those drives were all different and it is pretty difficult to measure such a degradation in performance in a consistent way (.. and they don't explain how they produced those catastrophic throughputs for the article). If you did not notice severe degrading performance (which must be attributed to the drive), I would not worry about that. Just dd the SDD with /dev/zero when you plan to re-install and be happy that it is faster than any Hdds that fits the machine anyway. And use trim of course, if it supports that + the wiki tricks for relatime etc.

jbrind

Member

Registered: 2013-09-18

Posts: 3

Re: SSD Secure Erase Fails

I don't have personal experience with those SSD models, but to my understanding you are right (i.e. you cannot use secure erase). 

OTOH the secure erase ATA funtion mainly serves the purpose to safely wipe the whole drive (incl. cache area) from data. The so-called 'cell-clearing' for SSDs is just a side effect, as I understand it. The ATA security commands existed in HDDs before there were SSDs and particularly the early SSD models all had big curves to get the firmware right. Some vendors offered DOS tools (as mentioned in the article too). Maybe you find something like that with asus (I would not bet on it).

The link you post has good explanations, but those drives were all different and it is pretty difficult to measure such a degradation in performance in a consistent way (.. and they don't explain how they produced those catastrophic throughputs for the article). If you did not notice severe degrading performance (which must be attributed to the drive), I would not worry about that. Just dd the SDD with /dev/zero when you plan to re-install and be happy that it is faster than any Hdds that fits the machine anyway. And use trim of course, if it supports that + the wiki tricks for relatime etc.

Makes sense to me. I've given up on a hardware reset and just reformatted, my partitions weren't aligned to the erase blocks so I fixed that. A basic dd write test completes around 50% faster which I'm quite satisfied with! This will hopefully translate into a noticeable speed boost after all the wiki SSD optimisations.

Cheers.